Messages in this thread |  | | | Date | Tue, 28 Mar 2000 11:38:44 -0700 | | From | yodaiken@fsmlabs ... | | Subject | Re: 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/
|  |