[docs] [issue36538] _thread.interrupt_main() no longer interrupts Lock.wait

[Gregory P. Smith]

New submission from Gregory P. Smith <greg at krypto.org>:

In Python 2.7 our threading implementation was so poor that a thread join ultimately called our lock wait implementation that busy looped polling and sleeping to check for a lock acquisition success.  calling thread.interrupt_main() which is just PyErr_SetInterrupt() C API in disguise successfully broke out of that lock wait loop.

In Python 3 with our drastically improved threading implementation, a lock wait is a pthreads sem_timedwait() or sem_trywait() API call, blocking within the pthreads library or OS kernel.  PyErr_SetInterrupt() obviously has no effect on that.  Only an actual signal arriving can interrupt that.

Thus instead of code using _thread.interrupt_main() - in 2and3 compatible applications, six.moves._thread.interrupt_main() - they should instead write:

 os.kill(os.getpid(), signal.SIGINT)

Given that _thread is a private module making _thread.interrupt_main() a private API, do we need to keep it?  If we do, we should at least document this behavior and recommend actually sending the signal.  It is less capable of actually interrupting the main thread from some common blocking operations today.  Sending the signal seems like it would always be better.

----------
assignee: docs at python
components: Documentation, Extension Modules, Library (Lib)
messages: 339518
nosy: docs at python, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: _thread.interrupt_main() no longer interrupts Lock.wait
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36538>
_______________________________________