[lkml]   [1997]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Killing clones (threads)
    Date wrote:
    > Werner Almesberger:
    > : Since POSIX requires that a signal sent to the process is delivered to
    > : exactly (*) one thread, ...
    > Hmm. Reading 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 /

     \ /
      Last update: 2005-03-22 13:40    [W:0.046 / U:2.056 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site