On Tue, 8 Aug 2017 14:29:41 -0700 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).
For the record, there are issues open for this: - locks not interruptible on Windows: https://bugs.python.org/issue29971 - enable optimized locks on Windows: https://bugs.python.org/issue29871 Having Lock.acquire() be interruptible would be really nice as it's the basis for so many of our synchronization primitives (including Thread.join(), I believe). Regards Antoine. _______________________________________________ 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
