Re: 2.2: TaskID's for CLONE_PID? Proper signal handling?
Peeter Joot (peeter@joot.com)
Tue, 6 Jan 1998 22:44:43 -0500
>Having given it some thought, here's how I would like to see signals behave in a threaded process. Note it assumes use of CLONE_PID, so that the concept of a "process container" of N threads is possible.
>
>Synchronous signals (e.g. SIGFPE, SIGILL, etc.) are sent to the thread that caused them.
>
>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.
>
>Directed signals (such as delivered by pthread_kill are delivered to the identified thread.
>
>I believe this is per the POSIX spec. If the Linux community wanted to extend or allow modification of this behavior, it would seem something could be done using the flags in the sigaction structure.
Hi Steve,
Yes, this is what basically I recall seeing in the posix spec (actually draft
8 -- I don't know what changed since then).
With LinuxThreads or other clone based threads the syncronous signals should
already be send to the thread that caused them. Directed signals are also
okay.
Among the things to be fixed is the signal handling for a signal directed to
the process or process group. These fixes are included in the CLONE_PID
changes that I am working on. Once the signal goes to a specific
thread (such as the manager thread in LinuxThreads) it is free to redirect
the signals to the first unblocked thread available.
Peeter