[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 09:55:55AM -0800, Jeremy Fitzhardinge wrote:
    > On 28-Mar-00 wrote:
    > >> IMHO, at least sharing PIDs would be a useful thing. Signal queues
    > >> would be nice, but there are other ways to deal with that.
    > >
    > > Can someone tell me why:
    > >
    > > pthread_creat( ....)
    > > if this is the first created thread
    > > rootpid = getpid();
    > > redefine getpid === return rootpid
    > >
    > > Doesn't work?
    > That would solve the problem of a given thread seeing its own thread, but it
    > doesn't deal with the problem of pthread signal semantics. Under pthreads, if
    > you send a signal to a process (a bunch of threads), it can be handled by any
    > thread which isn't blocking that signal. Linux only allows you to send signals
    > to a particular task. If you put all the tasks into a group you could signal
    > them all, but that's not right either, since the signal could be handled
    > multiple times by multiple threads.
    > J

    Let the manager be the only one to call the "real" signal functions and
    have the other threads make calls to the manager

    pthread_kill(thread,n) == kill(thread_to_realpid(thread),n)
    sigqueue(grouppid,n ...) ==
    real_sigqueue(find_thread_not_blocking(n),n ...)


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