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 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 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, 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. >> >> >> _______________________________________________ >> 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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4