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 mattbillenstein, ned.deily, neologix, njs, pitrou, ronaldoussoren, vstinner
Date 2017-06-26.11:46:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Ok, I think I've managed to dig to the core issue.  It is actually the same issue as (which was wrongly closed as fixed, apparently :-)).

Py_AddPendingCall() calls PyThread_acquire_lock() to try and take the pending calls lock.  Unfortunately, PyThread_acquire_lock() is not reentrant in the case where semaphores are not used (e.g. on OS X).  We can probably fix that first issue by calling pthread_mutex_trylock() instead of pthread_mutex_lock().

There is a second more fundamental issue, though, which is that PyThread_acquire_lock() calls into functions that are not async-signal-safe (see for a list).  So, depending on the particular OS and libc implementation, PyThread_acquire_lock() can fail in mysterious ways (including hang the process) when called from a signal handler.

So perhaps the ultimate fix would be to remove the OS-based locking in Py_AddPendingCall and use a busy spinwait...  The performance implications may be bad, though.
Date User Action Args
2017-06-26 11:46:23pitrousetrecipients: + pitrou, ronaldoussoren, vstinner, ned.deily, njs, neologix, mattbillenstein
2017-06-26 11:46:23pitrousetmessageid: <>
2017-06-26 11:46:23pitroulinkissue30703 messages
2017-06-26 11:46:23pitroucreate