Thank you Nathaniel for the response!
Really interesting and helpful.
2017-08-08 20:51 GMT+02:00 Nathaniel Smith :
> On Tue, Aug 8, 2017 at 2:54 AM, Jonathan Slenders
> wrote:
> > Hi all,
> >
> > Is it possible that thread.join() cannot be interrupted on Windows,
> while it
> > can be on Linux?
> > Would this be a bug, or is it by design?
> >
> >
> > import threading, time
> > def wait():
> > time.sleep(1000)
> > t = threading.Thread(target=wait)
> > t.start()
> > t.join() # Press Control-C now. It stops on Linux, while it hangs on
> > Windows.
>
> This comes down to a difference in how the Linux and Windows low-level
> APIs handle control-C and blocking functions: on Linux, the default is
> that any low-level blocking function can be interrupted by a control-C
> or any other random signal, and it's the calling code's job to check
> for this and restart it if necessary. This is annoying because it
> means that every low-level function call inside the Python interpreter
> has to have a bunch of boilerplate to detect this and retry, but OTOH
> it means that control-C automatically works in (almost) all cases. On
> Windows, they made the opposite decision: low-level blocking functions
> are never automatically interrupted by control-C. It's a reasonable
> design choice. The advantage is that sloppily written programs tend to
> work better -- on Linux you kind of *have* to put a retry loop around
> *every* low level call or your program will suffer weird random bugs,
> and on Windows you don't.
>
> But for carefully written programs like CPython this is actually
> pretty annoying, because if you *do* want to wake up on a control-C,
> then on Windows that has to be laboriously implemented on a
> case-by-case basis for each blocking function, and often this requires
> some kind of cleverness or is actually impossible, depending on what
> function you want to interrupt. At least on Linux the retry loop is
> always the same.
>
> The end result is that on Windows, control-C almost never works to
> wake up a blocked Python process, with a few special exceptions where
> someone did the work to implement this. On Python 2 the only functions
> that have this implemented are time.sleep() and
> multiprocessing.Semaphore.acquire; on Python 3 there are a few more
> (you can grep the source for _PyOS_SigintEvent to find them), but
> Thread.join isn't one of them.
>
> 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.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
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
