Author ronaldoussoren
Recipients Trundle, aronacher, benjamin.peterson, exarkun, loewis, ned.deily, pitrou, ronaldoussoren, stutzbach
Date 2010-09-16.13:27:56
SpamBayes Score 4.6132e-08
Marked as misclassified No
Message-id <>
In-reply-to <>
On 16 Sep, 2010, at 14:36, Armin Ronacher wrote:

> Armin Ronacher <> 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:

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.
Date User Action Args
2010-09-16 13:27:59ronaldoussorensetrecipients: + ronaldoussoren, loewis, exarkun, pitrou, benjamin.peterson, ned.deily, stutzbach, aronacher, Trundle
2010-09-16 13:27:57ronaldoussorenlinkissue9867 messages
2010-09-16 13:27:56ronaldoussorencreate