[issue21772] platform.uname() not EINTR safe

[Charles-François Natali]

Changes by Charles-François Natali :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> handle EINTR in the stdlib

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Stefano Borini]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[M.-A. Lemburg]

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

___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Stefano Borini]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Charles-François Natali]

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 EINTR" means calling PyErr_CheckSignals() which may raises a Python 
> exception (ex: KeyboardInterrupt).

It's good, we all agree on that.
I think the different EINTR-related reports should be closed as #18885
duplicates.
Then we need a patch for #18885: my idea was to write a pair of macros
similar to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS that would
handle the retry logic, instead of having to check for EINTR and
calling Py_CheckPendingSignals() everywhere.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[STINNER Victor]

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 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 EINTR" means calling PyErr_CheckSignals() which may raises a Python 
exception (ex: KeyboardInterrupt).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Marc-Andre Lemburg]

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 may cause the call to fail (e.g. in case the host name includes 
> non-ASCII chars)."
> 
> I also expect ASCII, but I prefer os.fsdecode() because it's the encoding 
> used almost everywhere in Python 3. It's for example the encoding (and error 
> handler) currently used by _syscmd_uname() indirectly by TextIOWrapper.

Ok.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[STINNER Victor]

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 expect ASCII, but I prefer os.fsdecode() because it's the encoding used 
almost everywhere in Python 3. It's for example the encoding (and error 
handler) currently used by _syscmd_uname() indirectly by TextIOWrapper.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Marc-Andre Lemburg]

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: _syscmd_uname() is currently only used to determine the processor, 
which will most likely always be ASCII.

BTW: It would be good to replace all other calls to os.popen() by subprocess as 
well. platform.py in Python 3 no longer has the requirement to stay compatible 
with earlier Python 2 releases.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +neologix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Tor Colvin]

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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[STINNER Victor]

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._syscmd_uname('-p'). I 
didn't reproduce the issue on Python 2.7 or 3.5.

---
import platform
import threading

def test():
for x in range(100):
p = platform._syscmd_uname('-p')

threads = [threading.Thread(target=test) for n in range(100)]
for thread in threads:
thread.start()
for thread in threads:
thread.join()
---

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[STINNER Victor]

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

--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file35659/platform_syscmd_uname.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Ned Deily]

Changes by Ned Deily :


--
nosy: +lemburg

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21772] platform.uname() not EINTR safe

[Tor Colvin]

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 is a suggested fix.

--
files: platform.py.fix
messages: 220654
nosy: Tor.Colvin
priority: normal
severity: normal
status: open
title: platform.uname() not EINTR safe
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35646/platform.py.fix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com