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 eryksun
Recipients Kevin Shweh, SnoopJeDi, bjs, eryksun, pitrou, serhiy.storchaka, vstinner
Date 2022-02-12.08:46:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1644655567.56.0.12209884858.issue46726@roundup.psfhosted.org>
In-reply-to
Content
> The race on := is much smaller than the original race 
> and I suspect in practice will be very hard to hit.

In Windows, the acquire() method of a lock can't be interrupted. Thus, in the main thread, an exception from Ctrl+C gets raised as soon as acquire() returns. This exception definitely will interrupt the assignment. Here's a workaround:

global scope:

    _WINDOWS = _sys.platform == 'win32'

in _wait_for_tstate_lock():

            acquired = None

            try:
                if acquired := lock.acquire(block, timeout):
                    lock.release()
                    self._stop()
            except:
                if _WINDOWS and acquired is None:
                    acquired = True
                if acquired:
                    lock.release()
                    self._stop()
                raise
                
This doesn't help in POSIX if the STORE_FAST instruction that assigns `acquired` gets interrupted. This can't be distinguished from acquire() itself getting interrupted. But at least the window for this is as small as possible.
History
Date User Action Args
2022-02-12 08:46:07eryksunsetrecipients: + eryksun, pitrou, vstinner, serhiy.storchaka, Kevin Shweh, bjs, SnoopJeDi
2022-02-12 08:46:07eryksunsetmessageid: <1644655567.56.0.12209884858.issue46726@roundup.psfhosted.org>
2022-02-12 08:46:07eryksunlinkissue46726 messages
2022-02-12 08:46:07eryksuncreate