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 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.
On Fri, Aug 30, 2013 at 10:02 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 30 Aug 2013 12:29:12 +0200I don't have any precise opinion on this. It's true that we should have
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?
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.
Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
--
--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