[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.083 / U:2.824 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site