2014-09-01 12:15 GMT+01:00 Marko Rauhamaa <ma...@pacujo.net>:
> Charles-François Natali <cf.nat...@gmail.com>:
>
>>> Which raises an interesting question: what happens to the os.read()
>>> return value if SIGINT is received?
>>
>> There's no return value, a KeywordInterrupt exception is raised.
>> The PEP wouldn't change this behavior.
>
> Slightly disconcerting... but I'm sure overriding SIGINT would cure
> that. You don't want to lose data if you want to continue running.
>
>> As for the general behavior: all programming languages/platforms
>> handle EINTR transparently.
>
> C doesn't. EINTR is there for a purpose.
Python is slightly higher level than C, right? I was referring to
Java, go, Haskell...
Furthermore, that's not true: many operating systems actually restart
syscalls by default (including Linux, man 7 signal):
"""
Interruption of system calls and library functions by signal handlers
If a signal handler is invoked while a system call or library
function call is blocked, then either:
* the call is automatically restarted after the signal handler
returns; or
* the call fails with the error EINTR.
Which of these two behaviors occurs depends on the interface
and whether or not the signal handler was established using the
SA_RESTART flag (see sigaction(2)). The
details vary across UNIX systems; below, the details for Linux.
"""
The reason the interpreter is subject to so many EINTR is that we
*explicitly* clear SA_RESTART because the C-level signal handler must
be handled by the interpreter to have a chance to run the Python-level
handlers from the main loop.
There are many aspects of signal handling in Python that make it
different from C: if you want C semantics, stick to C.
I do not want to have to put all blocking syscalls within a try/except
loop: have a look at the stdlib code, you'll see it's really a pain
and ugly. And look at the number of EINTR-related syscalls we've had.
_______________________________________________
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
