[lkml]   [2000]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Slow pthread_create() under high load
    Date writes:

    > I think you've misunderstood my idea. The data that is copied is
    > simply the information about what threads are announcing an intetion
    > to accept what signals.

    Signals sent to the process ID must be distributed to the next
    available thread. Since you (currently) cannot send signals to all
    threads you have to send them to a special thread (= manager) which
    then has to distribute them.

    > But the POSIX standard permits such races -- no?

    These are races which cannot happen normally. SIGSTOP is not
    propagated to the user level. Therefore there has to be a mechanism
    (would perhaps be possible with ptrace) to find stopped threads and do
    the same for all the others. ptrace() is not really a solution so I
    realy hae currently not the slightest idea how to implement it. The
    consequence is that you currently cannot stop multi-threaded
    applications with ^S. Only the initial thread is stopped.

    > Right. All that is taken care of. The mechanism just makes sure that
    > the actual kill or sigqueue call is directed to a thread (process) that
    > is willing to accept the signal.

    How do you want to redirect? The kernel does not provide this
    functionality. Again, if I call

    kill (ID_of_the_process, SIG)

    the implementation has to

    - look whether there is any thread waiting for this signal (sigwait);
    if yes, deliver it

    - see if there is none, see whether any thread is not blocking it; if yes
    devliver it

    - see if there is any thread non ignoring the signal; in this case the signal
    has to be cured to be eventually get delivered to the next thread
    unblocking the signal or to be discarded if the last threads marks the
    signals as to be ignored

    - otherwise call threads ignore the signal and it has to be discarded

    There must be a central handling of the signals. Either in active
    form (= manager) or in passive form as with the shared signal queue.
    I very much prefer the shared signal queue since it also can handle

    ---------------. drepper at ,-. 1325 Chesapeake Terrace
    Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
    Red Hat `--' drepper at `------------------------

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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