Messages in this thread | | | From | Xavier Leroy <> | Subject | Re: 2.2: TaskID's for CLONE_PID? Proper signal handling? | Date | Wed, 7 Jan 1998 16:19:49 +0100 (MET) |
| |
> Synchronous signals (e.g. SIGFPE, SIGILL, etc.) are sent to the > thread that caused them. > > Directed signals (such as delivered by pthread_kill are delivered to > the identified thread.
This is as per POSIX, yes.
> Asynchronous signals (e.g. SIGINT, the real-time signals. etc.) are > sent to an arbitrary thread that doesn't have the signal blocked. If > all threads have the signal blocked, and a thread is executing > sigwait (or sigwaitinfo), it is delivered via this mechanism.
Actually, sigwait unblocks the signals it is waiting for, so you don't have to make a special case for it.
If all threads have the signal blocked, you need to queue the signal on a process-wide basis, and deliver it later to the first thread that unblocks the signal.
> In the programming environment which I worked in previously > (LynxOS), this type of signal behavior made it easy to implement the > main thread as the "signal handling thread" in a completely > synchronous manner using sigwaitinfo. Thus, some applications could > have a signal handling thread, a GUI thread, and an "intense > processing"" thread.
Agreed, this is one of the most reasonable ways to handle signals in a multi-threaded application.
- Xavier Leroy
| |