On Fri, Aug 30, 2013 at 10:57 AM, Guido van Rossum <guido@python.org> wrote:
I don't have a strong opinion on this either. The distinction between send() and send_all() makes sense to me though (send_all() works hard to get all your data out, send() only does what it can quickly).

Personally for calls like select() I think returning early on EINTR makes sense, it's usually part of a select loop anyway.

The only thing I care deeply about is that you shouldn't restart anything before letting a Python-level signal handler run. A program might well have a Python signal handler that must run before the I/O is restarted, and the signal handler might raise an exception (like the default SIGINT handler, which raises KeyboardInterrupt).

I see http://bugs.python.org/issue18885 has been filed to track this discussion so we should probably move it there (I've added comments).

TL;DR you can't simply retry a system call with the exact same arguments when you receive an EINTR. There are some system calls for which that will not do what the programmer intended.
 


On Fri, Aug 30, 2013 at 10:02 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 30 Aug 2013 12:29:12 +0200
Charles-François Natali <cf.natali@gmail.com> wrote:
>
> Furthermore, the stdlib code base is not consistent: some code paths
> handle EINTR, e.g. subprocess, multiprocessing, sock_sendall() does
> but not sock_send()...
> Just grep for EINTR and InterruptedError and you'll be amazed.
>
> GHC, the JVM and probably other platforms handle EINTR, maybe it's
> time for us too?

I don't have any precise opinion on this. It's true that we should have
a systematic approach, I just don't know if all interfaces should
handler EINTR automatically, or only the high-level ones.
(for the sake of clarity, I'm fine with either :-))

Regards

Antoine.



--
--Guido van Rossum (python.org/~guido)

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org