Signal handling - Async functions and multi threaded applications, Signal stack

Question

Can someone explain why we should not call non async functions from signal handlers ? Like the exact sequence of steps that corrupt the programs while calling with such functions. And, does signals always run on separate stack ? if so is it a separate context or it runs on the context of the signaled thread ? Finally, in case of a multi-threaded system what happens when signal handler is executed and some other thread is signaled and calls the same signal handler ? (I am trying to develop deep understanding of signals and its applications)

Answer 1

When a process receives a signal, it is handled in the context of the process. You should only use aync-safe functions or re-entrant functions from inside a signal handler. For instance, you cannot call a malloc() or a printf() within a signal handler. The reason being:

*) Lets assume your process was executing in malloc when you received the signal. So the global heap data structures are in an inconsistent state. Now if you acquire the heap lock from inside your signal handler and make changes you will further render the heap inconsistent.

*) Another possibility is if the heap lock has been acquired by your process when it received the signal, and then you call malloc() from your signal handler, it sees that lock is held and it waits infinitely to acquire the lock (infinitely because the thread that can release the lock will not run till the signal is completely handled).

2) Signals run in the context of the process. As for the signal stack you can look at this SO answer -> Do signal handers have a separate stack?

3) As for getting multiple instances of the same signal you can look at this link -> Signal Handling in UNIX where Rumple Stiltskin answers it well.

Answer 2

I know some Solaris. So I'm using that for details. LWP==Solaris for "thread" as in pthreads.

trap signals like SIGILL, are delivered to the thread that caused the trap. Asynchronous signals are delivered to the first active thread (LWP), or process that is not blocking that signal. A kernel module called aslwp() traverses the process-header table (has associated LWP's) looking for the first likely candidate to receive the asynch signal.

A signal stack lives in the kernel. I'm not sure what/how to answer your signal stack question. One process may have several pending signals. Is that what you mean?

Each signal destined for a process is held there until the process switches context (or is forced) into the active state. This in part because you generally cannot incur a trap when the process context has been swapped out and the process does nothing cpu-wise. You certainly can incur asynch signals. But the process cannot "do anything" with any signal if it cannot run. So, at this point the kernel swaps the context back to active, and the signal is delivered via aslwp().

Realtime signals behave differently, and I'm letting it stay with that.

Try reading this:

developers.sun.com/solaris/articles/signalprimer.html