Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: New HPC-GAP guard checking without using ward #2845
base: master
Are you sure you want to change the base?
WIP: New HPC-GAP guard checking without using ward #2845
Changes from all commits
115687e
ed182a5
61f7972
b550ef9
b6b175f
2a63fb8
b75b536
b29c2d4
60e052a
6055041
e2bf918
2a660cb
48177e2
8ade01f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't
RetypeBag
need this as well?Also, shouldn't it be inside an
#ifdef HPCGAP
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, this push went through prematurely. I've been experimenting with various checks on the header functions.
ResizeBag()
seems to not cause any problems; but other functions — such asSIZE_BAG()
— do when you add guards to them. This seems to be mostly related to some internal kernel objects, for reasons that I don't fully understand yet.If I add checks to
BAG_HEADER()
directly, this seems to cause an overhead on the order of 10%, possibly a bit less (with clang).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing I never understood: Why don't we need some kind of read/write guard in
BAG_HEADER
as well? Right now, is there anything that would stop two threads from using ResizeBag/RetypeBag concurrently, possibly leading in a garbage output?(This thought just motivated me to submit PR #3884).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are dealing with two cases here. One is
TNUM_OBJ()
, which we don't want to burden with additional guard checks, as it's used all the time. Changes are generally either harmless or in the rare cases where they do matter, handled explicitly. The biggest unpleasantness here isKTNumPlist()
, which has an explicit guard check for this reason.You are correct that with resizing read-only objects, we run into a problem. I believe the code has assumed that the functions that resize objects (such as
GROW_PLIST()
would fail naturally when changing the length word in the object). However, it looks like sometimes the change happens rather late.I'd still simply add a write guard to
ResizeBag()
, where it causes minimal overhead, rather than making all accesses to the header more expensive.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, I don't want to burden TNUM_BAG, SIZE_BAG, TEST_OBJ_FLAGS with guards; but they can be written to, and so at least RetypeBage / ResizeBag and perhaps also the SET/CLEAR_OBJ_FLAGS functions should have guards... I always wondered why they didn't.