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

[Steve Dower]

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/thread_nt.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