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
Replace ReentrantMutex by a futex-based one on Linux. #95727
Replace ReentrantMutex by a futex-based one on Linux. #95727
Changes from all commits
c62c8cb
bd61bec
ebebe6f
319a9b0
43651aa
83e8b9e
5b25912
8a2c9a9
d4e44a6
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.
That might not work if a thread doesn't unlock and then exits. Another new thread may then suddenly acquire the lock if the allocator happens to return the same pointer.
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.
There is a ThreadId type you can use instead.
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.
That should work out fine, as the old thread doesn't exist anymore, it's fine for the new thread to take over ownership of the lock.
I am aware, but the ThreadId type is 64-bit, which is problematic on some 32-bit platforms.
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.
Should we avoid creating new
thread_local!
? Since pthread keys number available on some platforms is rather small, it would be beneficial for std to use as few pthread keys as possible.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.
That'd be nice.
I used the address of the THREAD_INFO thread local in an earlier version, to avoid creating a new one, but that one needs Drop, which makes it inaccessible during thread shutdown. We don't have a good way of getting the address of such a thread local's storage after its destructor ran, since its getter function just returns None after destruction.
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.
It looks like
LOCAL_PANIC_COUNT
meets this requirement, but it's a little weird to use it directly. maybe it would be nice to combine theKEYS
of map.rs andLOCAL_PANIC_COUNT
into oneLOCAL_THREAD_STATE
.