[lkml]   [2000]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Slow pthread_create() under high load
    On Tue, Mar 28, 2000 at 11:41:19AM -0800, Ulrich Drepper wrote:
    > writes:
    > > So the nonmanager threads do
    > > sigaction(n,s)
    > > === save local copy of s,n,thread_id
    > > real_sigaction(realprocessid(myid));
    > > if unblocked a signal that is user_space pending
    > > kill self with that signal
    > >
    > > Now the information about who blocks what is available in user space
    > >
    > > kill(gettpid(),n) where gettpid has been fixed to get the
    > > root pid
    > > === find someone who is not blocking and
    > > kill(someone,n)
    > > if all threads block, then mark signal
    > > as pending
    > You are completely neglecting that the signals are not coming alone:
    > - there is a signal context. If the process which receives the signal
    > first (mainly the manager) simply returns the signal context on its
    > stack is lost.

    Perhaps I'm missing something, but my idea was that the manager would
    not be sent any signals by other threads.

    > Copying it means garbage collection of some kind

    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.

    > - you have to handle certain signal special (segfault, stop/continue).
    > Especially the later contains the possibility for arbitrary many
    > races if not done in the kernel.

    But the POSIX standard permits such races -- no?

    > - RT signals have to transport data which, again, can be in the signal stack.
    > - sigaltstack must continue to work

    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. The race potential is only when
    thread A is concurrently blocking signal N while thread B is trying to
    send it and selected A as the destination. But that seems solvable.

    > I'm cutting it short here.
    > --
    > ---------------. drepper at ,-. 1325 Chesapeake Terrace
    > Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
    > Red Hat `--' drepper at `------------------------

    Victor Yodaiken
    FSMLabs is a servicemark and a service of
    VJY Associates L.L.C, New Mexico.

    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.021 / U:68.176 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site