[issue21772] platform.uname() not EINTR safe

Changes by Charles-François Natali : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> handle EINTR in the stdlib ___ Python tracker ___ ___

[issue21772] platform.uname() not EINTR safe

Stefano Borini added the comment: Wouldn't it make sense to use the same strategy used in the subprocess fix (that is, retry?). See http://hg.python.org/cpython/rev/6e664bcc958d/ -- ___ Python tracker

Re: [issue21772] platform.uname() not EINTR safe

On 08.07.2014 11:40, Stefano Borini wrote: > > You can't use subprocess. platform is used during build. subprocess needs > select, but select is a compiled module and at that specific time in the > build process is not compiled yet. Good point :-) -- Marc-Andre Lemburg eGenix.com ___

[issue21772] platform.uname() not EINTR safe

Stefano Borini added the comment: You can't use subprocess. platform is used during build. subprocess needs select, but select is a compiled module and at that specific time in the build process is not compiled yet. -- nosy: +stefanoborini ___ Pytho

[issue21772] platform.uname() not EINTR safe

Charles-François Natali added the comment: > I'm surprised that the Python read() method doesn't handle EINTR internally. > > I'm in favor of handling EINTR internally almost everywhere, I mean in the > Python modules implemented in the C, not in each call using these C methods. > "handling EIN

[issue21772] platform.uname() not EINTR safe

STINNER Victor added the comment: "2.7.6 or 3.4.1 with OS X 10.8. I can only reproduce it an automated test environment when the load is high on the machine. I've also seen it with 10.6/10.7. It's definitely inconsistently reproducible." I'm surprised that the Python read() method doesn't hand

[issue21772] platform.uname() not EINTR safe

Marc-Andre Lemburg added the comment: On 17.06.2014 11:21, STINNER Victor wrote: > > STINNER Victor added the comment: > > "I'm not sure whether using os.fsencoding() is a good idea. The encoding used > by uname is not defined anywhere and it's possible that Python using a wrong > encoding ma

[issue21772] platform.uname() not EINTR safe

STINNER Victor added the comment: "I'm not sure whether using os.fsencoding() is a good idea. The encoding used by uname is not defined anywhere and it's possible that Python using a wrong encoding may cause the call to fail (e.g. in case the host name includes non-ASCII chars)." I also expec

[issue21772] platform.uname() not EINTR safe

Marc-Andre Lemburg added the comment: I'm not sure whether using os.fsencoding() is a good idea. The encoding used by uname is not defined anywhere and it's possible that Python using a wrong encoding may cause the call to fail (e.g. in case the host name includes non-ASCII chars). Then again

[issue21772] platform.uname() not EINTR safe

Changes by Antoine Pitrou : -- nosy: +neologix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue21772] platform.uname() not EINTR safe

Tor Colvin added the comment: 2.7.6 or 3.4.1 with OS X 10.8. I can only reproduce it an automated test environment when the load is high on the machine. I've also seen it with 10.6/10.7. It's definitely inconsistently reproducible. -- ___ Python tra

[issue21772] platform.uname() not EINTR safe

STINNER Victor added the comment: > Calling f.read() on naked os.open() output can produce "IOError: [Errno 4] > Interrupted system call". Attached is a suggested fix. I cannot reproduce your issue. What is your exact Python version and OS? I tried to run 100 threads calling 100 times platform

[issue21772] platform.uname() not EINTR safe

STINNER Victor added the comment: Here is a different but similar patch for _syscmd_uname(): - use os.fsdecode() to use the locale encoding instead of latin-1 - use subprocess.DEVNULL to redirect errors to /dev/null - use "with proc:" to ensure that the subprocesss is cleaned in case of error --

[issue21772] platform.uname() not EINTR safe

Changes by Ned Deily : -- nosy: +lemburg ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue21772] platform.uname() not EINTR safe

New submission from Tor Colvin: platform.uname() periodically spews EINTR errors on mac - so use subproces.communicate() which is EINTR safe after http://bugs.python.org/issue1068268 Calling f.read() on naked os.open() output can produce "IOError: [Errno 4] Interrupted system call". Attached