Guido van Rossum added the comment: On Sat, Aug 31, 2013 at 9:56 AM, Charles-François Natali <rep...@bugs.python.org> wrote: > > Charles-François Natali added the comment: > > Gregory, thanks, that's what I was planning to do. > > But since the recent discussions (mainly on selectors), there are points I > obviously don't - and won't - agree with (such as select() returning EINTR or > returning early, same for sleep()), I'm not interested in this anymore.
Whoa. Maybe you're overreacting a bit? I personally see a big divide here between system calls whose functionality includes sleeping (e.g. sleep(), poll(), select()) and those that just want some I/O to complete (e.g. recv(), send(), read(), write()). The former are almost always used in a context that can handle premature returns just fine, since the return value for a premature return is the same as for hitting the deadline, and the timeout is often used just as a hint anyway. It's the latter category (recv() etc.) where the EINTR return is problematic, and I think for many of those the automatic retry (after the Python-level signal handler has been run and conditional on it not raising an exception) will be a big improvement. > Anyone interested can pick this up, though. > > (BTW, as for applications relying on EINTR being returned, I'm positive *way > more applications* will break because of the recent change making file > descriptors close-on-exec by default). Again, I'd make a distinction: I agree for send(), recv() etc., but I don't think there are many buggy uses of select()/poll() timeouts around. (And even if there are, I still think it's better to fix these by correcting the retry logic in the framework or the application, since it may have other considerations.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18885> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
