Antoine Pitrou <pit...@free.fr> added the comment: 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)) ---------- components: +Interpreter Core, Tests nosy: +gregory.p.smith, rnk type: -> behavior _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11223> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
