Message255499
| Author |
vstinner |
| Recipients |
alanwilter, georg.brandl, jdemeyer, martin.panter, neologix, nirai, pitrou, vstinner |
| Date |
2015年11月27日.22:44:50 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1448664291.07.0.490158465015.issue9504@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|