[Python-Dev] Interrupt thread.join() with Ctrl-C (original) (raw)

[Python-Dev] Interrupt thread.join() with Ctrl-C / KeyboardInterrupt on Windows

Steve Dower steve.dower at python.org
Tue Aug 8 20🔞46 EDT 2017

On 08Aug2017 1512, Nathaniel Smith wrote:

On Tue, Aug 8, 2017 at 2:29 PM, Steve Dower <steve.dower at python.org> wrote:

On 08Aug2017 1151, Nathaniel Smith wrote:

It looks like Thread.join ultimately ends up blocking in Python/threadnt.h:EnterNonRecursiveMutex, which has a maze of #ifdefs behind it -- I think there are 3 different implementation you might end up with, depending on how CPython was built? Two of them seem to ultimately block in WaitForSingleObject, which would be easy to adapt to handle control-C. Unfortunately I think the implementation that actually gets used on modern systems is the one that blocks in SleepConditionVariableSRW, and I don't see any easy way for a control-C to interrupt that. But maybe I'm missing something -- I'm not a Windows expert. I'd have to dig back through the recent attempts at changing this, but I believe the SleepConditionVariableSRW path is unused for all versions of Windows. A couple of people (including myself) attempted to enable that code path, but it has some subtle issues that were causing test failures, so we abandoned all the attempts. Though ISTR that someone put in more effort than most of us, but I don't think we've merged it (and if we have, it'd only be in 3.7 at this stage). Ah, you're right -- the comments say it's used on Windows 7 and later, but the code disagrees. Silly me for trusting the comments :-). So it looks like it would actually be fairly straightforward to add control-C interruption support.

Except we're still hypothesising that the native condition variables will be faster than our emulation. I think until we prove or disprove that with a correct implementation, I'd rather not make a promise that Ctrl+C will work in situations where we depend on it.

That's not to say that it isn't possible to continue fixing Ctrl+C handling in targeted locations. But I don't want to guarantee that an exception case like that will always work given there's a chance it may prevent us getting a performance benefit in the normal case. (I'm trying to advise caution, rather than saying it'll never happen.)

Cheers, Steve

More information about the Python-Dev mailing list