SUMMARY: SIGCHLD confuses popen()?

From: Peter C. Chapin (pchapin@ecet.vtc.edu)
Date: Wed Jan 29 2003 - 06:44:04 EST


Thanks to Dr. Thomas Blinn for his reply. The full text of my question
appears below.

Here is a summary of Dr. Blinn's note: "My suspicion (and it's only a
suspicion) is that when the child process is reaped, part or all of the
output that has not yet been read is lost. It may be a bug in Tru64
UNIX, or it may just be good luck that it works (or at least seems to
work) on some other implementations (e.g., Linux)."

After reflecting on this some more it occurs to me that the difference
between Tru64's behavior and Linux's behavior might be in how popen() is
implemented or in how the two systems schedule processes. It seems like,
in the case of Tru64, the helper process is running to completion before
popen() even returns. Thus the child process is reaped (and it's output
thrown away?) before the parent can read the child's output. Perhaps
under Linux, popen() returns at once and the child doesn't run until its
output is needed at which point it is read immediately and not lost.

In any case, I suspect the observed behavior is probably in the bounds
of normal on both systems. It's probably the program that is undefined.

Peter

-----> cut here <-----

> One of my students is building a server program that installs a signal
> handler for the SIGCHLD signal. The program creates a child for every
> connection and then reaps the children in the signal handler (most likely
> while the main loop is blocked in accept()). There are no problems with
> this part.
>
> However, the student is also using popen() during the initialization of
> the program to spawn a helper process. It happens that he is doing this
> after setting up signal handling. Thus when the helper process terminates,
> the SIGCHLD handler is run. This apparently confuses popen() because
> subsequent attempts to read the helper process's output return nothing.
> (I'm assuming the helper process terminates before popen() returns... it
> produces only a single line of output and does not need to wait for
> anything). However, if the signal handling is temporarly removed, the
> output of the helper process can be read fine.
>
> The program works normally as written on our Linux system but displays the
> behavior I describe here on Tru64 v5.1A. Is there some Tru64 specific
> interaction between signals and popen() that we need to know about? Or
> were we just lucky that it worked on Linux?



This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:05 EDT