[mypyc] Add librt.threading.Lock class#21690
Merged
Merged
Conversation
This reverts commit 9b2bc222edf9780fb10a0f108ab8b098b78a2c84.
This reverts commit ce077a4726d47bd494bd9b09e3210b2c96979527.
This comment has been minimized.
This comment has been minimized.
p-sawicki
reviewed
Jul 7, 2026
Comment on lines
+229
to
+236
| // Fast path: grab the lock without releasing the GIL if it is free. | ||
| AcquireSRWLockExclusive(&self->srw); | ||
| if (!self->locked) { | ||
| self->locked = 1; | ||
| ReleaseSRWLockExclusive(&self->srw); | ||
| return 1; | ||
| } | ||
| ReleaseSRWLockExclusive(&self->srw); |
Collaborator
There was a problem hiding this comment.
this is the same as the non-blocking path so we could drop the non-blocking path. instead always try the fast path and return 0 on failure if !blocking.
Comment on lines
+271
to
+280
| { | ||
| int status; | ||
| do { | ||
| status = sem_trywait(&self->sem); | ||
| } while (status == -1 && errno == EINTR); | ||
| if (status == 0) { | ||
| self->locked = 1; | ||
| return 1; | ||
| } | ||
| } |
Collaborator
There was a problem hiding this comment.
same here - could merge the non-blocking/fast paths.
Comment on lines
+326
to
+333
| // Fast path: grab the lock without releasing the GIL if it is free. | ||
| pthread_mutex_lock(&self->mut); | ||
| if (!self->locked) { | ||
| self->locked = 1; | ||
| pthread_mutex_unlock(&self->mut); | ||
| return 1; | ||
| } | ||
| pthread_mutex_unlock(&self->mut); |
Co-authored-by: Piotr Sawicki <sawickipiotr@outlook.com>
Co-authored-by: Piotr Sawicki <sawickipiotr@outlook.com>
p-sawicki
approved these changes
Jul 7, 2026
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
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
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.
The new native
Lockclass is a partial replacement forthreading.Lock. It's much faster thanthreading.Lockin compiled code. In a microbenchmark I saw ~2.5x to ~4x performance improvement over compiled code using stdlib.The Lock type has four platform-specific backends:
All backends preserve threading.Lock semantics (cross-thread release allowed) and drop the GIL while blocking.
Added optimized handling of
with lock:statements (forlibrt.threadingonly).There is one significant known regression compared to CPython (beyond missing features): if two threads race to release the same lock, this triggers undefined behavior. The PyMutex C API doesn't provide a way to avoid this without a massive performance cost, so I decided to keep this limitation instead of sacrificing performance, as performance is the main goal of the new type.
This is just a lock -- using it with
threading.Conditionis not supported. We may later decide to add a nativeCondition(and possibly other synchronization primitives).I used heavy coding agent assist with small, incremental changes, and multiple review iterations. I left the rather verbose comments generated by coding agents, since the code is legitimately tricky.