Gregory P. Smith added the comment: ... Code review:
In socket_eintr.5.patch I don't think the thread safety concerns about the s.settimeout() calls being done from Python code should be an issue but I'll ponder that for a bit. When you've got a socket s, why would code ever be calling s.recv() in one thread while calling another method on the same socket s in another thread? That seems unwise. (For UDP it might be a valid thing to do but it still has an odd smell to it) If you're worried about timer resolution, just check that the new timeout value "deadline - now" is less than the previous timeout value and if not, ensure the value decreases by some small amount. So long as it continually goes down, it will eventually timeout. Even if the duration isn't accurate in the face of a bunch of EINTRs, this is a degenerate case; it should still be reasonable behavior. On POSIX systems using os.times()[4] rather than an absolute time.time(), which can be changed out from underneath the process (even though that is rare on functioning systems), could be useful. But conditionally using that seems overly complex. I wouldn't bother. ... Side discussion Some things in 2.7 related to EINTR have already been fixed in the past few years such as data loss in readline() and IIRC writelines(). Correctness isn't a feature. Do you consider it an API change to prevent an error that nobody relies on or even expects (as PEP 475 notes) and virtually no code is written to properly handle when it _does_ happen? I don't. It is a bug fix. It's mostly a matter of if we can do it sanely and in a maintainable manner. Please don't WONTFIX this issue, I intend to get safe fixes in. ... Motivation The underlying motivation here is to enable the use of a signal based sampling profiler on a program that is using Python 2.7 (entirely, or embedded as one part of a larger C/C++ application). Signals (SIGPROF) used in that scenario cause EINTR returns from syscalls that otherwise rarely (read: never) have them in most environments. Result: Bugs show up making such a sampling profiler impossible to deploy in practice until those issues are fixed. Fixing the Python standard library is high value as it is a higher up place where these can be handled properly as you cannot even use some standard library modules at all otherwise because the unhandled EINTR surfaces too late or causes other unrecoverable errors internally before you see it. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23863> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
