[issue9504] signal.signal/signal.alarm not working as expected

[STINNER Victor]

STINNER Victor added the comment:

I don't understand this issue.

I would expect that a system call fails with EINTR if it is interrupted by a signal. Python explicitly configures the C library to get EINTR errors: automatic retry is disabled when Python sets its signal handlers.

If a system call doesn't fail, what shoud we do with the result, especially when reading data (read/recv)?

Yes, we _can_ checks to check regulary if we got a C signal by adding checks, but it's unclear to me if we must raise the exception immediatly, or later. Immedialty if I understand correctly the initial message. So should we check *all* system calls, or only system calls well known to block on I/O, like read/write, send/recv, select, etc.?

Do we try to workaround design choices by the Linux kernel and the GNU libc?

Right now, my favorite choice would be to do nothing. Yes, sometimes signals are delayed. Sometimes, a signal doesn't interrupt immediatly a blocked program. It's not perfect. But it's already very complex, I'm not sure that I want to make the code even more complex to check for signals in more places.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________