Repository navigation
_thread module docs: update yet another bullet point in the *caveats* list #125058
Description
Documentation
[Note: This issue is, in a way, a continuation of gh-125025.]
Near the end of the documentation of the _thread module there is a list of caveats. One of them – the third one – seems no longer accurate:
It is not possible to interrupt the acquire() method on a lock — the KeyboardInterrupt exception will happen after the lock has been acquired.
– whereas it appears that (since Python 3.2) lock acquisitions can be interrupted by signals, at least on platforms using Pthreads.
Activity
zuo commentedon Oct 7, 2024
The question is whether nowadays the possibility to interrupt a blocking acquisition of a lock is possible only on POSIX systems (I can observe that on my Linux system), or maybe also on others? (i.e., Windows?)
Unfortunately I am not sure what is the right answer, therefore a Python threading expert needs to speak up.
According to the Experts Index the right persons are you, @gpshead and @pitrou. I hope, this is the right way to ask you for help?
Thank you in advance! :)
zuo commentedon Oct 7, 2024
PS I'd happy to provide a PR with an appropriate docs patch – when I'm sure what is the state of affairs when it comes the possibility to interrupt a lock acquisition on platforms with a non-Pthreads-based threads implementation.
gpshead commentedon Oct 7, 2024
Yes POSIXish platforms should happily allow interrupting
threading.Lock.acquire()with ^C at this point. @zooba or @eryksun wear Windows hats and can answer for that platform.zooba commentedon Oct 7, 2024
Looks like Windows is using
EnterNonRecursiveMutex()for this, which is not going to be interruptible (based on a quick look - trust Eryk's opinion over mine here).In order to be interruptible, it needs to be a
WaitForMultipleObjectsincluding the_PyOS_SigintEventhandle. I don't think it's trivial to convert, at least not without a performance loss, and likely with subtle behaviour changes from what it currently does.zuo commentedon Oct 8, 2024
@gpshead @zooba Thank you for your feedback! I presume that something along the lines of the following would be appropriate:
zuo commentedon Oct 8, 2024
PS Perhaps adding that
pitrou commentedon Oct 8, 2024
I think this used to be the case, but it got replaced by the faster native mutex for performance.
colesbury commentedon Oct 8, 2024
@kumaraditya303 has a PR to use
PyMutexfor_thread.lock, which blocks using analertable (interruptible?)WaitForSingleObjectEx call:_thread.lock#125110colesbury commentedon Oct 8, 2024
My previous comment was incorrect.
PyMutexcallsWaitForSingleObjectExwithbAlertable=FALSE:cpython/Python/parking_lot.c
Line 114 in e99f159
zuo commentedon Oct 8, 2024
OK, so it remains platform-dependent whether
acquire()is interruptible, doesn't it?pitrou commentedon Oct 8, 2024
Yes. But concretely, it's interruptible on POSIX, not on Windows.
pitrou commentedon Oct 8, 2024
Regardless, it seems the
bAlertableflag has nothing to do with being interruptible with Ctrl-C:https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobjectex
pythongh-125058: update `_thread` docs regarding interruptibility of …
zuo commentedon Oct 8, 2024
PR is ready :)
gh-125058: update `_thread` docs regarding interruptibility of `lock.…
pythongh-125058: update `_thread` docs regarding interruptibility of …
pythongh-125058: update `_thread` docs regarding interruptibility of …
[3.13] gh-125058: update `_thread` docs regarding interruptibility of…
[3.12] gh-125058: update `_thread` docs regarding interruptibility of…