Noob <root@127.0.0.1> writes:
Hello everyone,
Suppose process A forks/execs process B, and immediately sends a signal
to process B.
int child_pid = fork();
if (child_pid == 0) // child
execv("/bin/progB", argv);
// parent
kill(child_pid, 64);
Assume the first thing progB does is to install a handler for signal 64.
It seems to me that there is a race:
If process B runs first after the fork, then all is well, B installs the handler,
then process A sends the signal, and everyone lives happily ever after.
However, if process A runs first after the fork, the OS delivers the signal before process B enters main(), perhaps even before it execs. Process B then terminates in agony.
Does this fall under the "don't do that!" rule?
Yes.
Or perhaps program A is expected to set the signal mask for
progB before even calling fork()?
That would be a sensible way to handle this: If b must handle the
signal, it must inherit a signal masks which blocks it to be able to
install its handler reliaby before getting hit with the signal.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)