On 16 Sep, 2010, at 14:36, Armin Ronacher wrote:

> 
> Armin Ronacher <armin.ronacher@active-4.com> added the comment:
> 
>> Wouldn't retrying on EINTR cause havoc when you try to interrupt a process?
> 
> All your C applications are doing it, why should Python cause havok there?  Check the POSIX specification on that if you don't trust me.
> 
>> That is: what would happen with the proposed patch when a python script
>> does a read that takes a very long time and the user tries to interrupt 
>> the script (by using Ctrl+C to send a SIGTERM)?
> EINTR is only returned if nothing was read so far and the call was interrupted in case of fread.
> 
> Here a quick explanation from the GNU's libc manual:
> http://www.gnu.org/s/libc/manual/html_node/Interrupted-Primitives.html

You conveniently didn't quote the part of my message where I explained why I think there may be a problem.

CPython's signal handlers just set a global flag to indicate that a signal occurred and run the actual signal handler later on from the main interpreter loop, see signal_handler in Modules/signal.c and intcatcher in Parser/intrcheck.c.  

The latter contains the default handler for SIGINT and that already contains code that deals with SIGINT not having any effect (when you sent SIGINT twice in a row without CPython running pending calls the interpreter gets aborted). 

Because Python's signal handlers only set a flag and do the actual action later on blindly rerunning system calls when errno == EINTR may result in programs that don't seem to react to signals at all.