2

Many books say that a time window exists between the generation and delivery of the signal when the signal is not blocked.

So I wonder whether the time window still exists when the signal is not blocked or the generation and delivery of the signal are a atomic operation?

If the time window still exists, what will happen when some other sigals (same or not the same to the signal geneated) are also generated during the time window?

1

Some of the answer to your questions depends on how the signal handler gets set up. I think we're looking at this in the context of setting signal handlers via the sigaction(2) system call.

One of the elements of a struct sigaction is named "sa_mask". From man 2 sigaction:

sa_mask  gives  a  mask of signals which should be blocked during execution of the
signal handler.  In addition, the signal which triggered the handler will be 
blocked, unless the SA_NODEFER flag is used.

It looks like if you set up correctly, even the signal being handled isn't blocked. Personally, I can't imagine a use for that, but I have a notoriously limited imagination.

So, I would say "yes, there's a window between signal generation and invocation of the receiving processes signal handler". So, other signals could get generated and sent to the receiving process. As far as what happens to those "other signals": it looks like signals aren't "queued": see this stackoverflow answer, except for "real time" signals. That is, if the kernel gets a bunch of kill(some_pid, SIGHUP), the process denoted by some_pid will have it's SIGHUP signal handler function invoked once.

  • One possible reason to offer an option not to block the signal during its handler's execution is if you wanted compatibility with the old signal() system call. – Mark Plotnick Mar 20 '14 at 23:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.