Menu
237
A signal is a notification to a process that an event has occurred, and can be sent by the kernel, another process, or by itself. The delivery of a signal is asynchronous. You can send a signal to a process using the kill system call.
A default signal handler is associated with every signal that the kernel runs when handling that signal. User-defined signal handler can override this default action that is called to handle the signal. Signals are handled in different ways.
You can use the sigprocmask function to block signals while you modify global variables that are also modified by the handlers for these signals. You can set sa_mask in your sigaction call to block certain signals while a particular signal handler runs.
About delivery of signals, TLPI states that signals are "normally" delivered when a task is next scheduled, when switching from kernel mode to user mode, or "immediately" when the task is already running (presumably "immediately" would have to happen by firing an interrupt first, otherwise how could it do that). Well, whatever this means, it is not strictly binding, but it's very close to what happens.
You have to distinguish between realtime and "normal" signals as well as between "normal" signals that are generated synchronously, most of the time because of a hardware event (e.g. segmentation fault) and those that aren't (they're genereated asnychronously).
Realtime signals are queued, normal signals are not. That means that the implementation of normal signals is most likely merely something like one per-task word that serves as a bitmask.
Generating a "normal" signal means setting a bit, and when the OS next decides whether a signal has to be delivered, it tests the word against zero, and if necessary figures out which bit(s) were set, and calls the signal handler(s), if any, accordingly.
The only practical reason why one needs to know this is because it is possible to "lose" signals. If two or more signals are generated before the first is delivered, it's still only one signal alltogether.
The implementation of realtime signals (which are required to queue up to a implementation-dependent length) is obviously much more complicated.
Signals that happen because of a hardware event (e.g. segfault) are generated synchronously, in the same way as if the process called kill on itself (chapter 22.4 TLPI), i.e. they are delivered "immediately", for two reasons. First, it does not make sense to do something else, and second there is already a kernel/user switch happening when the trap handler returns. So delivery is always "immediately" anyway.
108
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
