read on pipe, interrupted system call

[Donn Cave]

Quoth Susan Williams <susan at Provis.com>:
| I'm using the commands.py library module, which is basically
| os.system using popen to give you the command's output.
| I'm running 1.5 on Solaris (threads and Tkinter linked in,
| the app is a Tkinter app with no threads).
|
| A number of commands are executed to do "ln -s file1 file2"
| using commands.getstatusoutput("ln -s ...").  This does a popen,
| gets a pipe in return, and does a read on the pipe.
| It is really common for the read to get an IOError exception 
| with value "Interrupted system call."  (but not every time!)
|
| I can't get it to fail in a simple example, only in this large
| application I've got that was written with 1.3, running on slow
| sparc 1's and 2's instead of the Ultra 10s and 60s I'm using
| now.
|
| Does this ring a bell with anyone?  I tried suppressing signals,
| and the complaint changes to "No child processes." as though the 
| signal in question might be SIGCHLD.  I don't think any alarms
| are set (I tried adding signal.alarm(0)).

I don't have any real answer, but since no one else has followed
up that I can see, here's some mumbling.

Your test hosts could be as bad off as the production host, only
less obvious because the C library may quietly ignore the EINTR
error and you get back abbreviated command output.

SIGCHLD is a skunk.  It's definitely worth a look through the
application and everything built into it, in case there's a
SIGCHLD handler that could be removed.  Or even just removed
after it's no longer needed.  After a signal(SIGCHLD, SIG_DFL),
your process won't get SIGCHLD signals at all - it's kind of
a weird signal in that way.  It's also kind of a weird signal
in other ways, especially I suspect if you're on a platform
that is still making the transition from System V SIGCLD, and
I don't have any Solaris host to experiment with, nor knowledge
thereof.

	Donn Cave, donn at u.washington.edu