lkml.org 
[lkml]   [1997]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Killing clones (threads)
Date
Andries.Brouwer@cwi.nl wrote:
> Werner Almesberger:
>
> : Since POSIX requires that a signal sent to the process is delivered to
> : exactly (*) one thread, ...
>
> Hmm. Reading 3.3.1.2: At the time of [signal] generation,
> a determination shall be made whether the signal has been generated
> for the process or for a specific thread within the process.

Yup, that's also what my copy says. And two paragraphs later, it says:

"Signals generated for the process shall be delivered to or accepted
by exactly one of those threads within the process."

So it's a two-step decision: if, say, a thread segfaults, it and no other
thread gets the signal for it. If, however, the source of the signal is
something as clumsy as kill() which only knows about PIDs (in POSIX), the
kernel has to search for a thread within that process that is willing to
handle the signal. If none is found, "the signal shall remain pending on
the process until either a thread calls the sigwait function selecting
that signal, a thread unblocks delivery of the signal, or the action
associated with the signal is set to ignore the signal." (NB: they don't
say what happens with that poor pending signal if the process should
decide to terminate without previously unblocking the signal.)

Strictly speaking, a "kill all threads" functionality in kill() violates
POSIX (as kill() should deliver zero or one signal to threads, but never
more than one), but I'm not sure if we really care about this heavily
theoretical argument ...

- Werner

--
_________________________________________________________________________
/ Werner Almesberger, DI-LRC,EPFL,CH werner.almesberger@lrc.di.epfl.ch /
/_IN_R_133__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
\
 
 \ /
  Last update: 2005-03-22 13:40    [from the cache]
©2003-2011 Jasper Spaans