CODEWITHSUNDEEP
kernelpthreadsposix
crozzfire
crozzfire

Reputation: 196

Why doesn't sigwait() respect changes in sigset?

In pthreads: Assume I have a thread to handle CTRL+C inputs, initialized as:

sigemptyset(&set);
sigaddset(&set, SIGINT);
pthread_sigmask(SIG_BLOCK, &set, NULL);
pthread_create(&ctrlc_handler, NULL, ctrlc_handler_impl, data);

The thread then starts and waits for the SIGINT with sigwait() as:

int signal;
sigwait(&set, &signal);

Now, if I need to unblock (and not cancel or destroy) this thread, the only way I am able to do it right now is to send a SIGINT explicitly with pthread_kill(..., SIGINT). Although this works well, it feels very intrusive and out of context. Perhaps it would be cleaner to be able to simply unblock this thread by removing the SIGINT from the sigset with: sigdelset(&set, SIGINT). The sigwait() would pick this up and unblock since the sigset becomes empty. But for some reason this doesn't work. It was perhaps an early design decision and I am curious why it doesn't work.

Upvotes: 1

Views: 129

Answers (1)

Kaz
Kaz

Reputation: 58608

The first hurdle that the set of signals passed into sigwait is likely copied inside the kernel; meanwhile you're manipulating the original copy.

Nothing in the specification of sigwait says that manipulating the set from another thread has any effect on the waiting thread.

Such a specification would be fairly unreasonable, because it would add up to a requirement for a memory operation on a data object in user space to have the effect of trapping into the scheduler to wake up a thread.

Upvotes: 3

Related Questions