On 08Aug2015 17:08, Chris Angelico <ros...@gmail.com> wrote:
On Sat, Aug 8, 2015 at 4:56 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
On Fri, Aug 7, 2015 at 8:44 PM, Chris Angelico <ros...@gmail.com> wrote:
The exception isn't happening inside sock.accept(), as I explained. So
you can't catch it there.
Where does the exception happen then? Your explanation only covered
why the blocking call cannot be interrupted by it, not why the
exception isn't simply raised when the blocking call finishes.
I'm not sure there's anything in the language spec about it; at least,
I can't find it. But the last time I was digging in the Python/C API,
there was a caveat that KeyboardInterrupt was raised *at some point
after* Ctrl-C was hit - a flag gets set, and after every N bytecode
instructions, the flag is checked, and then the signal gets raised. It
might happen on only some platforms, and I can't even find back the
page I was looking at when I read that. Maybe someone else knows?
From:
https://docs.python.org/3/library/signal.html#execution-of-python-signal-handlers
we have:
A Python signal handler does not get executed inside the low-level (C) signal
handler. Instead, the low-level signal handler sets a flag which tells the
virtual machine to execute the corresponding Python signal handler at a later
point(for example at the next bytecode instruction).
and in the next section "Signals and threads" it says:
Python signal handlers are always executed in the main Python thread, even
if the signal was received in another thread.
Cheers,
Cameron Simpson <c...@zip.com.au>
Meddle not in the affairs of dragons,
for you are crunchy and good with ketchup.
--
https://mail.python.org/mailman/listinfo/python-list
