Message255499
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. |
|
Date |
User |
Action |
Args |
2015-11-27 22:44:51 | vstinner | set | recipients:
+ vstinner, georg.brandl, pitrou, nirai, neologix, alanwilter, martin.panter, jdemeyer |
2015-11-27 22:44:51 | vstinner | set | messageid: <1448664291.07.0.490158465015.issue9504@psf.upfronthosting.co.za> |
2015-11-27 22:44:51 | vstinner | link | issue9504 messages |
2015-11-27 22:44:50 | vstinner | create | |
|