lkml.org 
[lkml]   [2000]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Slow pthread_create() under high load
On Tue, Mar 28, 2000 at 09:55:55AM -0800, Jeremy Fitzhardinge wrote:
>
> On 28-Mar-00 yodaiken@fsmlabs.com 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 ...)

etc.



--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [from the cache]
©2003-2011 Jasper Spaans