This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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.
History
Date User Action Args
2015-11-27 22:44:51vstinnersetrecipients: + vstinner, georg.brandl, pitrou, nirai, neologix, alanwilter, martin.panter, jdemeyer
2015-11-27 22:44:51vstinnersetmessageid: <1448664291.07.0.490158465015.issue9504@psf.upfronthosting.co.za>
2015-11-27 22:44:51vstinnerlinkissue9504 messages
2015-11-27 22:44:50vstinnercreate