|
Home > Archive > Unix Programming > January 2004 > help with sigaction
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
help with sigaction
|
|
| Guillaume 2004-01-23, 5:32 pm |
| Hello,
I'm new to UNIX programing and have some problem with the signal
management.
My app consist in a main that creates 10 new processes, each of them send
a SIGUSR1 to the father when it has finished.
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
bypass
althought I have enabled SA_NODEFER, (refering to man sigaction, it should
not)
Here's the code I use in the main :
struct sigaction saFather;
saFather.sa_handler = handlerFather;
saFather.sa_flags = SA_NODEFER ;
sigemptyset(&saFather.sa_mask);
sigaction(SIGUSR1, &saFather, NULL);
I'm working on SunOS 5.8.
Thanks a lot.
| |
| Paul Pluzhnikov 2004-01-23, 5: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.
|
|
|
|
|