<br><div class="gmail_quote">On Thu, Feb 17, 2011 at 5:46 PM, Philip Winston <span dir="ltr"><<a href="mailto:pwinston@gmail.com">pwinston@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
We have a multiprocess Python program that uses Queue to communicate<br>
between processes.  Recently we've seen some errors while blocked<br>
waiting on Queue.get:<br>
<br>
IOError: [Errno 4] Interrupted system call<br>
<br>
What causes the exception?  Is it necessary to catch this exception<br>
and manually retry the Queue operation?  Thanks.<br>
<br>
We have some Python 2.5 and 2.6 machines that have run this program<br>
for many 1,000 hours with no errors.  But we have one 2.5 machine and<br>
one 2.7 machine that seem to get the error very often.<font color="#888888"><br></font></blockquote><div><br>You're getting this:<br><br>#define  EINTR     4 /* Interrupted system call */<br><br></div></div>It most likely means that a signal is interrupting a system call (an interaction with the kernel, not just os.system).<br>
<br>Google for EINTR for more info.<br><br>Whatever callable is getting this error, at root, probably should be dealing with retrying the system call that got interrupted.  However, it can sometimes be dealt with higher in the call stack, as a sort of bandaid.<br>
<br>This is sadly frequently ignored in application programming.  It's some kernel dev's favorite complaint about us.<br><br>One good way of dealing with this is to use the following function, wrapped around any system calls:<br>
<br>def retry_on_eintr(function, *args, **kw):<br>   while True:<br>      try:<br>         return function(*args, **kw)<br>      except OSError, e:<br>         if e.errno == errno.EINTR:<br>            continue<br>         else:<br>
            raise<br><br>If you find standard library code that's failing to deal with EINTR, it's legitimate to submit a bug report about it.<br><br>Another way around the issue is to avoid signals.  But that's not always practical.<br>
<br>How can you tell what's using system calls?  It can be hard, but you can usually use strace or truss or ktrace or par or trace to find out.  You can also add a little code to log all your tracebacks somewhere, inspect the log periodically, and add a retry_on_eintr as needed in the places identified.  Also, most *ix's will have a .h somewhere listing them - on one of my Ubuntu systems, it's at /usr/include/bits/syscall.h.<br>
<br><br><br><br>