sys.stdout.write on Python 2.7 is not EINTR safe #66206

Activity

1. jstewmon commented on Jul 18, 2014

   

   jstewmonmannequin

   on Jul 18, 2014

   MannequinAuthor

   More actions

   Writing to sys.stdout on OS X can fail with IOError: [Errno 4] Interrupted system call.

   I have observed this while trying to write to sys.stdout when SIGCHLD is received. The script below consistently reproduces the problem with python 2.7.2 on OS X 10.9.3.

   import sys
   import os
   import signal
   import subprocess
   import time
   
   
   children = {}
   def claim_child():
       pid, status = os.wait()
       p = children.pop(pid)
   
   def trap(sig, frame):
       claim_child()
   
   signal.signal(signal.SIGCHLD, trap)
   
   running = 0
   max_procs = 70
   program = [sys.executable, '-c', 'import sys, time; print sys.version; time.sleep(3)']
   f = sys.stdout # crashes with: IOError: [Errno 4] Interrupted system call
   # f = file('/tmp/eintr.log', 'w') # works just fine
   while True:
       while len(children) < max_procs:
           f.write('starting program: {}\n'.format(program))
           p = subprocess.Popen(program)
           children[p.pid] = p
       time.sleep(0.05)
2. jstewmon

   added

   topic-IO

   on Jul 18, 2014
3. ned-deily commented on Jul 18, 2014

   

   ned-deily

   on Jul 18, 2014

   Member

   More actions

   There have been a number of EINTR-releated issues reported in the past, some unique to BSD-based systems and/or OS X; see for example, bpo-9867 and bpo-12268. I don't know that any of them specifically addressed problems with writes to Python 2 file objects. FWIW, with your test case, I'm not able to reproduce a failure on 10.9.3 using python.org 2.7.8 or 2.7.3 or with the system 2.7.5. And, with a modified print(), I didn't see a failure with python.org 3.4.1, either. Can you say more about the origins of your Python 2.7.2? Have you tried with a current 2.7.8? How quickly does the test fail, e.g. after how many iterations?
4. vstinner commented on Jul 18, 2014

   

   vstinner

   on Jul 18, 2014

   Member

   More actions

   This issue is just an example of issue addressed by the issue bpo-18885.
5. ned-deily commented on Jul 18, 2014

   

   ned-deily

   on Jul 18, 2014

   Member

   More actions

   Yes, an issue not likely to be addressed in Python 2.7. I'm still curious as to why I'm not able to reproduce the problem, though. I suppose it could just come down to differences in the system it is running on, like workload, amount of memory, and/or number of processors.
6. jstewmon commented on Jul 18, 2014

   

   jstewmonmannequin

   on Jul 18, 2014

   MannequinAuthor

   More actions

   Sorry, I had a typo in the original report - I am actually using Python 2.7.7 installed with homebrew.

   The script crashes for me on the first iteration every time using iTerm as my terminal. I just tried it in Terminal, and it doesn't crash.

   Maybe it's actually an issue with iTerm?
7. vstinner commented on Jul 18, 2014

   

   vstinner

   on Jul 18, 2014

   Member

   More actions

   I can reproduce the issue on Linux:

   Traceback (most recent call last):
     File "x.py", line 26, in <module>
       f.write('starting program: {}\n'.format(program))
   IOError: [Errno 4] Interrupted system call
8. vstinner commented on Jul 19, 2014

   

   vstinner

   on Jul 19, 2014

   Member

   More actions

   I can reproduce the issue on Linux:

   Sorry, I forgot to mention that I reproduced the issue on Fedora 20 with Python 2.7.

   I cannot reproduce with Python 3.3.
9. ned-deily commented on Jul 20, 2014

   

   ned-deily

   on Jul 20, 2014

   Member

   More actions

   I also can reproduce this on Linux with Python 2.7 but not with 3.4 which uses a different io system. So the question is: is anyone interested in addressing this for Python 2 file objects?
10. ned-deily

    changed the title [-]sys.stdout.write on OS X is not EINTR safe[/-] [+]sys.stdout.write on Python 2.7 is not EINTR safe[/+] on Jul 20, 2014
11. vstinner commented on Jul 20, 2014

    

    vstinner

    on Jul 20, 2014

    Member

    More actions

    I'm interested to work on all EINTR issues, including Python 2.

    I'm working on a new PEP with Charles-François Natali to address *all* EINTR at once in Python 3.5. If the PEP is accepted, we may fix some EINTR issues on Python 2. Some changes change the behaviour and so cannot we done in Python 2. Well, the PEP is still a draft, we will see that later.
12. neologix

    closed this as completedon Jul 22, 2014
13. piotrdobrogost commented on Jul 30, 2014

    

    piotrdobrogostmannequin

    on Jul 30, 2014

    Mannequin

    More actions

    @hypo
    Is there any reason you keep this PEP "secret" :) by not mentioning it on bug 18885?
14. ezio-melotti

    transferred this issue fromon Apr 10, 2022