01-23-04 10:32 PM
"Guillaume" <potier.guillaume@wanadoo.fr> writes:
quote:
> My app consist in a main that creates 10 new processes, each of them send
> a SIGUSR1 to the father when it has finished.
Presumably they do so to notify the parent that they are done,
so it can wait() for them (and thus avoiding zombies).
Signals are never going to be a reliable solution to this.
If the parent doesn't really care when the child is done, and is
notified only so it can wait(), then you should use the 'double
fork()' technique, described in 3.13 of the UNIX FAQ.
If the parent really does need to know when the child terminated,
use waitpid(), possibly with WNOHANG option.
quote:
> The problem occurre when a signal is launch during the execution of the
> handler (due to a previous call to kill(getppid(),SIGUSR1);), this one is
That is probably *not* the problem. The problem probably is that
signals can not be reliably counted.
For example, if a process is blocked in a system call, and 2 separate
processes send it a SIGUSR1 in rapid succession via kill(), how
many times will the sugusr1 handler be invoked when the blocked
process is (eventually) unblocked? Once: the kernel doesn't count
how many signals were sent; it just remembers (in a bit mask)
which signals are pending (this is not true for real-time signals).
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
[ Post a follow-up to this message ]
|