repair hashtable-keys and similar with weakly held keys
#998
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit repairs a problem created by the previous commit (cisco#994), and it further repairs some hashtable operations alog the same lines as vector operations in that commit. The implementation of `eq?`-based hashtables turns off interrupts, but the parameter setting had no effect on the checks now inserted for `make-vector`. An interrupt can go wrong with operations like `hashtable-keys` with weekly held keys, because keys could disappear before being transferred to a newly allocated vector. The solution of not inserting an interrupt trap in `make-vector` when `generate-interrupt-trap` is `#f` seems like the obvious approach, but that interacts badly with wrappers for `make-vector` and similar as defined in "prims.ss". Instead, this commit adds a new procedure `$make-vector/no-interrupt-trap`. In general, functions that need to avoid interrupts must choose the functions they call carefully, anyway, and `make-vector` has become one that cannot be called. The repaired operations `$eq-hashtable-keys`, etc., now use `$make-vector/no-interrupt-trap`, but they also use `$use-trap-fuel` after the result is created. The `$eq-hashtable-copy` and `$eq-hashtable-clear` operations similarly need `$use-trap-fuel`, and they previously did not use `make-vector` or another operation that would have inserted interrupt checks.
burgerrg
approved these changes
Dec 1, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This commit repairs a problem created by the previous commit (#994), and it further repairs some hashtable operations alog the same lines as vector operations in that commit.
The implementation of
eq?-based hashtables turns off interrupts, but the parameter setting had no effect on the checks now inserted formake-vector. An interrupt can go wrong with operations likehashtable-keyswith weekly held keys, because keys could disappear before being transferred to a newly allocated vector.The solution of not inserting an interrupt trap in
make-vectorwhengenerate-interrupt-trapis#fseems like the obvious approach, but that interacts badly with wrappers formake-vectorand similar as defined in "prims.ss". Instead, this commit adds a new procedure$make-vector/no-interrupt-trap. In general, functions that need to avoid interrupts must choose the functions they call carefully, anyway, andmake-vectorhas become one that cannot be called.The repaired operations
$eq-hashtable-keys, etc., now use$make-vector/no-interrupt-trap, but they also use$use-trap-fuelafter the result is created. The$eq-hashtable-copyand$eq-hashtable-clearoperations similarly need$use-trap-fuel, and they previously did not usemake-vectoror another operation that would have inserted interrupt checks.