Ronald Oussoren <ronaldousso...@mac.com> added the comment: On 16 Sep, 2010, at 14:36, Armin Ronacher wrote:
> > Armin Ronacher <armin.ronac...@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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9867> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
