> >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.
Another thing that needs to be added is a CLONE_TRACE, and propbably
a CLONE_PARENT too to allow debugging of multithreaded programs. Funny
is that gdb 4.16 already supports it (when it gets a uknown pid from
the waitpid() that waits for the debugee it'll automagically add it to
its thread tables). Just the kernel doesn't support it yet. I'm not sure
if CLONE_TRACE should be folded into CLONE_PID or not. CLONE_PARENT
is probably obsolete then.
-Andi