handling SIGCHLD with multiple children
Brandon Gillespie
Is there _ANY_ way of finding what child sent a SIGCHLD signal to the
parent process? I have a situation where a parent may have multiple
children processing different tasks, and the parent is waiting for one
child to complete a specific task, which it cares about, but it does not
care about the other children. Because of this in most instances when
SIGCHLD is received it simply resets it and continues working, except for
now I need to handle things differently when a specific child sends
SIGCHLD. Is there any ANY way to figure out where it came from?
Thanks..
-Brandon
Gary Palmer
Brandon Gillespie wrote in message ID
<Pine.BSF.3.91.96070...@tombstone.sunrem.com>:
Do you really need to sit on SIGCHLD or can you use waitpid()? Or you
could perhaps even use waitpid() in the SIGCHLD handler, with WNOHANG
option, to see which child exited...
Gary
--
Gary Palmer FreeBSD Core Team Member
FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info
Brandon Gillespie
On Tue, 9 Jul 1996, Gary Palmer wrote:
> Brandon Gillespie wrote in message ID
> <Pine.BSF.3.91.96070...@tombstone.sunrem.com>:
> > Is there _ANY_ way of finding what child sent a SIGCHLD signal to the
> > parent process? I have a situation where a parent may have multiple
> > children processing different tasks, and the parent is waiting for one
> > child to complete a specific task, which it cares about, but it does not
> > care about the other children. Because of this in most instances when
> > SIGCHLD is received it simply resets it and continues working, except for
> > now I need to handle things differently when a specific child sends
> > SIGCHLD. Is there any ANY way to figure out where it came from?
>
> Do you really need to sit on SIGCHLD or can you use waitpid()? Or you
> could perhaps even use waitpid() in the SIGCHLD handler, with WNOHANG
> option, to see which child exited...
The server is a object oriented database driver (with its own interpreted
language), and the child is handling a backup pseudo-asyncrynously.
Basically it syncronizes its database on disk, sets it read-only and forks
a child which begins the actual backup. When the child is finished
copying the server knows to go back to a read/write db when it receives
the signal. However, there is also the possibility of other children with
different purposes being forked as well. Furthermore, the server is
handling network connections, and does NOT want to block while it backups,
due to the time involved with a sizeable database. I suppose I could just
use one of the SIGUSR* signals..
-Brandon Gillespie
Gary Palmer
> language), and the child is handling a backup pseudo-asyncrynously.
> Basically it syncronizes its database on disk, sets it read-only and forks
> a child which begins the actual backup. When the child is finished
> copying the server knows to go back to a read/write db when it receives
> the signal. However, there is also the possibility of other children with
> different purposes being forked as well. Furthermore, the server is
> handling network connections, and does NOT want to block while it backups,
> due to the time involved with a sizeable database. I suppose I could just
> use one of the SIGUSR* signals..
Why not go with my second suggestion? You can trap the SIGCHLD, and in
the handler do something like:
void
sig_child(int dummy)
{
int status;
if (waitpid(backup_pid, &status, WNOHANG) == backup_pid)
db_rw = TRUE;
}
This is rough code, written on the fly, and I suggest you read the
wait() manpage for more details.
Michael Hancock
On Tue, 9 Jul 1996, Terry Lambert wrote:
> The correct method would be to program in terms of an event loop; I
> don't know the architecture of the parent process, but if it is an
> event loop, then you can do the following:
You might want to contact Paul Vixie for his EventLib. It's a work in
progress the last time I checked but it looked pretty complete. BIND and
INND will probably be using this lib.
-mike
Michael L. VanLoon -- HeadCandy.com
>Is there _ANY_ way of finding what child sent a SIGCHLD signal to the
>parent process? I have a situation where a parent may have multiple
>children processing different tasks, and the parent is waiting for one
>child to complete a specific task, which it cares about, but it does not
>care about the other children. Because of this in most instances when
>SIGCHLD is received it simply resets it and continues working, except for
>now I need to handle things differently when a specific child sends
>SIGCHLD. Is there any ANY way to figure out where it came from?
What about using pipes and select?
-----------------------------------------------------------------------------
Michael L. VanLoon mich...@HeadCandy.com
--< Free your mind and your machine -- NetBSD free un*x >--
NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3,
Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32...
NetBSD ports in progress: PICA, others...
Roll your own Internet access -- Seattle People's Internet cooperative.
If you're in the Seattle area, ask me how.
-----------------------------------------------------------------------------
Terry Lambert
> Is there _ANY_ way of finding what child sent a SIGCHLD signal to the
> parent process? I have a situation where a parent may have multiple
> children processing different tasks, and the parent is waiting for one
> child to complete a specific task, which it cares about, but it does not
> care about the other children. Because of this in most instances when
> SIGCHLD is received it simply resets it and continues working, except for
> now I need to handle things differently when a specific child sends
> SIGCHLD. Is there any ANY way to figure out where it came from?
Signals are persistent conditions, not events.
A signal handler will block deliver of on signal behind.
It is therefore not a good idea to call wait in the SIGCHLD handler
itself, since it introduces apotential race condition in disposing
the signal.
The correct method would be to program in terms of an event loop; I
don't know the architecture of the parent process, but if it is an
event loop, then you can do the following:
1) Establish a SIGCHLD signal handler; if a SIGCHLD signal is
received, then a volatile variable should be set to indicate
one or more children need to be reaped.
2) Arrange the main loop as follows:
a) check the volatile flag; dispatch to inband handler
function if set
b) set SIGCHLD to interrupt system calls
c) call the main loop hang-pending-event call (usually
select or other system call)
d) on handler return, reset interrupt on SIGCHLD do only
the hang is interruptable.
d) check hang-pending-event return value for interrupt
e) if interrupted, go to top of main loop
3) Create an inband handler function for SIGCHLD; this function
will:
a) call wait(2) with WNOHANG option
b) on -1, processing is complete (no more PID's to return)
c) use the return value to hash-index a list of child
processes that are outstanding (return value is PID).
d) set a flag (does not need to be volatile) to indicate
that anyone waiting for this process to complete may
now proceed.
This approach was used successfully in a "X port monitor" to allow
management of logins on up to 32 terminals (highest tested amount;
highest theoretical amount was 256 becase of FD_SETSIZE) using a
single process (instead of running one xdm per X terminal -- a huge
memory waster on a Sun machine).
This approach was also successfully used for a pipe-based linkage
system, similar to that employed by Khoros, to similar effect for
a tools-based image processing "drag-and-drop" workbench.
Terry Lambert
te...@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.