Message79438
There is still a potential problem.
Figure the following:
- thread A executes ENTER_HASHLIB while lock is NULL; therefore, thread
A has released the GIL and doesn't hold any lock
- thread B enters EVP_update with a large buffer (it can be there, since
A doens't hold the GIL)
- thread B allocates the lock, releases the GIL, and allocates the lock
- thread A continues running and arrives at LEAVE_HASHLIB; there,
self->lock is not NULL anymore, so it tries to release it; since it
hasn't acquired it before, this may block forever (depending on the
platform I assume)
To remove this possibility, the macros should probably look like:
#define ENTER_HASHLIB(obj) \
{ \
int __lock_exists = ((obj)->lock) != NULL; \
if (__lock_exists) { \
if (!PyThread_acquire_lock((obj)->lock, 0)) { \
Py_BEGIN_ALLOW_THREADS \
PyThread_acquire_lock((obj)->lock, 1); \
Py_END_ALLOW_THREADS \
} \
}
#define LEAVE_HASHLIB(obj) \
if (__lock_exists) { \
PyThread_release_lock((obj)->lock); \
} \
} |
|
Date |
User |
Action |
Args |
2009-01-08 20:55:38 | pitrou | set | recipients:
+ pitrou, gregory.p.smith, vstinner, ebfe |
2009-01-08 20:55:38 | pitrou | set | messageid: <1231448138.03.0.998422167344.issue4751@psf.upfronthosting.co.za> |
2009-01-08 20:55:37 | pitrou | link | issue4751 messages |
2009-01-08 20:55:36 | pitrou | create | |
|