1

I'm working on a school assignment where I'm sending signals between two processes. Process 1 sends a signal to process 2, and then process 2 sends SIGUSR1 back to process 1 to acknowledge the original signal.

In process 2, I use sigsuspend to wait for SIGUSR1, however, I notice this function blocks indefinitely if I never set up a handler for SIGUSR1. As soon as I configure a dummy handler, sigsuspend works fine.

So I'm curious, if I'm just using a signal as a waiting mechanism before proceeding, why is it necessary for me to define a dummy nandler?

Izzo
  • 961

1 Answers1

0

Because in the POSIX standard sigsuspend is simply defined to only return if a signal not in mask is caught by a signal handler:

The sigsuspend() function shall replace the current signal mask of the calling thread with the set of signals pointed to by sigmask and then suspend the thread until delivery of a signal whose action is either to execute a signal-catching function or to terminate the process. […]

If the action is to terminate the process then sigsuspend() shall never return. If the action is to execute a signal-catching function, then sigsuspend() shall return after the signal-catching function returns, with the signal mask restored to the set that existed prior to the sigsuspend() call.

Even with sigsuspend the normal signal dispositions for a signal are processed:

  • an ignored signal doesn't interrupt the process normally, so it doesn't cause sigsuspend to return.
  • an terminating signal terminates the process, so sigsuspend can't return.
  • a signal with a handler causes the handler to run and then resumes programm execution, so sigsuspend can return after the handler finishes.

Normally (at least on Linux, FreeBSD and Mac OS X) SIGUSR1 should terminate the process, so your process 2 should exit instead of indefinitely blocking. Did you perhaps use signal(SIGUSR1, SIG_IGN) somewhere?

cg909
  • 7,082