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?

Or perhaps program A is expected to set the signal mask for
progB before even calling fork()?
It's too late after fork() because A can't touch B's sigmask.

Regards.

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.