On 08Aug2017 1512, Nathaniel Smith wrote:
On Tue, Aug 8, 2017 at 2:29 PM, Steve Dower <steve.do...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to