Application developers must be aware of significant differences in the handling of signals between DCE threads and typical single-threaded environments. In DCE threads, some signals are handled on a per-process basis, and some are handled on a per-thread basis. This topic explains the semantic details of DCE thread signal handling.
A signal is said to be generated for a process or thread when the event that causes the signal first occurs. Each process or thread has an action to be taken in response to each signal supported by the system or implementation. A signal is said to be delivered when the appropriate signal action for the process or thread is taken. A signal can be blocked or (masked) by a thread or process by establishing a signal mask containing the signal to be blocked.
The delivery of a blocked signal is deferred until it is unblocked. (Note that if the action specified for a signal is to ignore it, the signal effectively remains blocked.) During the time between its generation and delivery a signal is said to be pending.
Signals can be classified into the following two types, with differing semantics:
· Synchronous signals are generated by a specific thread and delivered to the same thread. Threads can establish nondefault per-thread signal handlers for synchronous signals by calling sigaction( ). Synchronous signals can be blocked on a per-thread basis by establishing per-thread signal masks.
· Asynchronous signals are generated by external events, not identifiable with a single thread. Asynchronous signals are handled on a per-process basis. An asynchronous signal is delivered exactly once to some thread in a process. All threads in a process share the same signal mask. Per-process handling of asynchronous signals can be established by calling sigwait( ).
DCE threads applications must handle synchronous and asynchronous signals differently.
More: