System V / SIGCLD questions...

[Panos Tsirigotis]

In article <565 at lehi3b15.csee.Lehigh.EDU> murrey at lehi3b15.csee.Lehigh.EDU (Erik Murrey) writes:
>
>Here's one I can't figure out...
>
>I'm writing a routine (like reapchildren(), found all over the place
>in BSD code), using the SIGCLD signal to invoke it.  Its job is to
>execute a wait(2) on all of the children that have died, getting their
>exit status, etc.
>
>Now for the problem:
>
>It seems (according to the man page for signal(2)) that during the
>signal handler for SIGCLD (reapchildren()), any further SIGCLD's will
>be ignored.  By the same token, I can't do a non-blocking wait() in
>System V, so I can't repeatedly call wait() (I might have other
>children that haven't exit()-ed yet)
>
>Here is what happens:
>
>If I have spawned a few children, and one just did an exit(), then my
>reapchildren() signal handler gets called.  It does a wait(), gets the
>exit status, and gets out of there (after resetting the SIGCLD
>signal).  If by chance a second child dies while we are within the
>reapchildren() handler, I never get notified of it...

I can see 2 solutions:
First solution:
Have each call to reapchildren() reap just 1 child. Since you got a
SIGCLD you know that at least 1 child id dead. The first thing
reapchildren() should do is to reset the signal handler for SIGCLD
so if another child dies while in reapchildren(), reapchildren() will
be called recursively. This solution has 2 problems:
a) There is a race between restoring the signal handler and receiving
another SIGCLD.
b) More that 1 child may have died but you only get 1 SIGCLD.

Second solution:
Before doing the wait in reapchildren() arrange to have a timer interrupt
in case wait blocks:
The code would look like this:
	alarm( 1 ) ;		/* no setitimer in System V */
	pid = wait( &status ) ;
	if ( pid == -1 )			/* you may want to check errno for EINTR too */
	{
		/* timer expired */
	}
	else
	{
		alarm( 0 ) ;		/* reset timer */
		do whatever processing is needed
	}

I think the second solution is better since it is more reliable.

Panos

----------------------------------------------------
| Email address: panos at boulder.colorado.edu        |
----------------------------------------------------