-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
Closed
Labels
3.13bugs and security fixesbugs and security fixesextension-modulesC modules in the Modules dirC modules in the Modules dirtopic-free-threadingtype-featureA feature request or enhancementA feature request or enhancement
Description
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:
- Modules/_blake2/blake2b_impl.c
- Modules/_blake2/blake2s_impl.c
- Modules/_hashopenssl.c
- Modules/hashlib.h
- Modules/md5module.c
- Modules/sha1module.c
- Modules/sha2module.c
- Modules/sha3module.c
Basic idea:
- Replace
PyThread_type_lock lockwithPyMutex. 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 GIL - Add a field
bool use_mutexto indicate if the code should lock the mutex. This should always be set totrueinPy_NOGIL. In the default build, we should dynamically set it totruein places where we previously allocatedself->lock - Update
ENTER_HASHLIBandEXIT_HASHLIBmacros.
Linked PRs
tonybaloney
Metadata
Metadata
Assignees
Labels
3.13bugs and security fixesbugs and security fixesextension-modulesC modules in the Modules dirC modules in the Modules dirtopic-free-threadingtype-featureA feature request or enhancementA feature request or enhancement