Why does Unix deliver signals this way?

Question

In Unix, when signals are posted, and the receiving process is running more than one thread, at first a thread is chosen to carry out the signal handling routine.

I don't understand why that is necessary or even makes sense. Doesn't the signal handling routine need it's own stack, register set, etc., anyway?

Answer 1

Sure, it needs its own stack and register set. But what thread context it's running in matters too. For one thing, that controls what work gets interrupted while the signal is processed.

For example, suppose thread A is holding a recursive lock and has changed some critical structure to an inconsistent state. That's fine though, because it won't release the lock until it returns those structures to a consistent state.

Now, say the signal interrupts thread A, and the signal handler goes to acquire the lock to check that critical structure. It gets the lock, because it's the thread that already holds the lock and the lock is recursive. Since it just got the lock that protects the critical structure, it expects to be able to access it and find it in an consistent state. But, of course, it's in a inconsistent state. Boom! You just crashed.

So in this case, the signal handler must always go to a thread that never acquires that lock. That way, when the signal handler acquires the lock, it is sure that no other code holds that lock and thus the structure must be in a consistent state.

It is common in multi-threaded code to have one thread whose sole purpose is to catch all external signals sent to the program. It handles the signals one-by-one, so the signal never interrupts code that might hold a lock.