Date: Tue, 9 Jul 1996 13:21:06 -0600 (MDT) From: Brandon Gillespie <brandon@tombstone.sunrem.com> To: Gary Palmer <gpalmer@FreeBSD.ORG> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: handling SIGCHLD with multiple children Message-ID: <Pine.BSF.3.91.960709131511.4876B-100000@tombstone.sunrem.com> In-Reply-To: <28527.836939654@palmer.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 9 Jul 1996, Gary Palmer wrote: > Brandon Gillespie wrote in message ID > <Pine.BSF.3.91.960709122409.4725A-100000@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960709131511.4876B-100000>