except block isn't catching exception
Cameron Simpson
cs at zip.com.au
Sat Aug 8 04:11:48 EDT 2015
On 08Aug2015 17:08, Chris Angelico <rosuav at gmail.com> wrote:
>On Sat, Aug 8, 2015 at 4:56 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> On Fri, Aug 7, 2015 at 8:44 PM, Chris Angelico <rosuav at 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 <cs at zip.com.au>
Meddle not in the affairs of dragons,
for you are crunchy and good with ketchup.
More information about the Python-list
mailing list