search

soarpenguin / python-multiprocessing

Automatically exported from code.google.com/p/python-multiprocessing
Other
0 stars 0 forks source link

EINTR not caught [patch] #13

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Hi, I'm using a vendor supplied C++ library that spawns internal threads
and communicates amongst those using signals. Unfortunately, this wreaks
havoc upon lots of Python packages, including multiprocessing. The basic
problem is that sometimes those signals hit other threads, interrupting
system calls and causing them to fail with EINTR. If the code wasn't
written with this in mind, it is this interruption, and treats it as a
normal error. Fixes 2 places in multiprocessing, however, now allows me to
run with the supplied library in heavy use for days at a time. Ideally, I
think all system calls in multiprocessing should be made safe from this
issue, but these two instances fixed things for me.

This was tested on Ubuntu 8.04 using its stock Python2.5 and was originally
based on the svn hosted at google code r54.

As this is obviously an issue in multiprocessing in core Python, should I
take it up there, too?

Original issue reported on code.google.com by dr.andre...@gmail.com on 16 Feb 2009 at 12:35

Attachments:

GoogleCodeExporter commented 9 years ago 
I might trivially change the loop from 

while 1:
    try:
        send(obj)
        break
    except IOError,err:
        if err.errno==errno.EINTR:
            continue
        raise

to

while 1:
    try:
        send(obj)
        break
    except IOError, err:
        if err.errno != errno.EINTR:
            raise

but that's just a matter of preference, not correctness.

Anyway, this patch looks great to me.  If anything, there might be additional 
system calls that could benefit from an EINTR test like this, but it's a start. 
 It's been about two years since this patch was initially submitted; have any 
python-multiprocessing developers had a chance to look at this?

By the way, checks for EINTR may or may not need to go into the stdlib version 
of multiprocessing.  Python 2.6 and later have signal.siginterrupt which make 
it easier to work around this.

Original comment by amcna...@gmail.com on 11 Mar 2011 at 7:09