This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients gregory.p.smith, pitrou, rnk, sable, vstinner
Date 2011-02-16.15:16:35
SpamBayes Score 8.247831e-06
Marked as misclassified No
Message-id <1297869396.53.0.941791964774.issue11223@psf.upfronthosting.co.za>
Ok, the problem is when the condition variable-based implementation is chosen in Python/thread_pthread.h.
It is actually reproduceable under Linux by adding `#undef USE_SEMAPHORES` just after `#define USE_SEMAPHORES`.
The problem is that, contrary to sem_timedwait(), pthread_cond_wait() doesn't have well-defined behaviour with signals. POSIX simply says:

“If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread resumes waiting for the condition variable as if it was not interrupted, or it shall return zero due to spurious wakeup.”

So, on those OSes where the semaphore API can't be used, the test can succeed or not depending on how pthread_cond_wait() behaves in the face of signals. It would be better if it didn't hang, though.

(This is not a regression, by the way. Locks were totally uninterruptible under POSIX until 3.2, and the tests weren't there. The new tests were introduced in r87292 (see issue8844))
Date User Action Args
2011-02-16 15:16:36pitrousetrecipients: + pitrou, gregory.p.smith, vstinner, sable, rnk
2011-02-16 15:16:36pitrousetmessageid: <1297869396.53.0.941791964774.issue11223@psf.upfronthosting.co.za>
2011-02-16 15:16:35pitroulinkissue11223 messages
2011-02-16 15:16:35pitroucreate