[Python-Dev] EINTR handling... (original) (raw)
Gregory P. Smith greg at krypto.org
Sat Aug 31 18:46:41 CEST 2013
- Previous message: [Python-Dev] EINTR handling...
- Next message: [Python-Dev] cpython: Issue #17741: Rename IncrementalParser and its methods.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Aug 30, 2013 at 10:57 AM, Guido van Rossum <guido at python.org> wrote:
I don't have a strong opinion on this either. The distinction between send() and sendall() makes sense to me though (sendall() 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 at pitrou.net>wrote: On Fri, 30 Aug 2013 12:29:12 +0200 Charles-François Natali <cf.natali at gmail.com> wrote: > > Furthermore, the stdlib code base is not consistent: some code paths > handle EINTR, e.g. subprocess, multiprocessing, socksendall() does > but not socksend()... > 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.
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido)
Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130831/80c4366c/attachment.html>
- Previous message: [Python-Dev] EINTR handling...
- Next message: [Python-Dev] cpython: Issue #17741: Rename IncrementalParser and its methods.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]