-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
Make hashlib related modules thread-safe without the GIL #111916
Closed
Labels
3.13
bugs and security fixes
extension-modules
C modules in the Modules dir
topic-free-threading
type-feature
A feature request or enhancement
Comments
colesbury
added
type-feature
A feature request or enhancement
3.13
bugs and security fixes
topic-free-threading
labels
Nov 9, 2023
Hey! I'd like to give this a try. I have a limited experience with cpython internals but I had a quick look at the code and it seems feasible to me 😅 |
Great, thanks! Let me know if you have any questions or there is anything I can help with. |
gpshead
pushed a commit
that referenced
this issue
Nov 15, 2023
aisk
pushed a commit
to aisk/cpython
that referenced
this issue
Feb 11, 2024
… GIL (python#111981) Always use an individual lock on hash objects when in free-threaded builds. Fixes python#111916
Glyphack
pushed a commit
to Glyphack/cpython
that referenced
this issue
Sep 2, 2024
… GIL (python#111981) Always use an individual lock on hash objects when in free-threaded builds. Fixes python#111916
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
3.13
bugs and security fixes
extension-modules
C modules in the Modules dir
topic-free-threading
type-feature
A feature request or enhancement
Feature or enhancement
The hashlib based modules already have some locking to make some operations thread-safe (with the GIL), but the logic isn't sufficient if running with the GIL disabled.
Relevant files:
Basic idea:
PyThread_type_lock lock
withPyMutex
. This should be both simpler and faster in general and avoid the need for dynamically assigning a lock, which can pose thread-safety issues without the GILbool use_mutex
to indicate if the code should lock the mutex. This should always be set totrue
inPy_NOGIL
. In the default build, we should dynamically set it totrue
in places where we previously allocatedself->lock
ENTER_HASHLIB
andEXIT_HASHLIB
macros.Linked PRs
The text was updated successfully, but these errors were encountered: