Antoine Pitrou <pit...@free.fr> added the comment: 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); \ } \ } _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4751> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com