Messages in this thread | | | Date | Tue, 28 Mar 2000 17:22:43 -0700 | From | yodaiken@fsmlabs ... | Subject | Re: Slow pthread_create() under high load |
| |
On Tue, Mar 28, 2000 at 12:13:32PM -0800, Ulrich Drepper wrote: > yodaiken@fsmlabs.com writes: > > > 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. > > Signals sent to the process ID must be distributed to the next > available thread. Since you (currently) cannot send signals to all > threads you have to send them to a special thread (= manager) which > then has to distribute them.
Signals generated by threads within a collection of threads can be directed to an appropriate destination by looking at the cached signal state of each thread: signal(root_process_id,n){ original_signal(thread_allowing(n),n); } Signals generated by processes outside the thread group can be directed to the manager thread which can then use the same mechanism to send them a second time, this time to the appropriate target. manager_handler: got a signal =n target = thread_allowing(n); if(!target) save thread data else kill/sigqueueu signal to thread
> > But the POSIX standard permits such races -- no? > > These are races which cannot happen normally. SIGSTOP is not > propagated to the user level. Therefore there has to be a mechanism > (would perhaps be possible with ptrace) to find stopped threads and do > the same for all the others. ptrace() is not really a solution so I
I don't follow this problem. When SIGSTOP is sent to a process all threads are supposed to stop. manager_sigstop_handler: forall threads kill(thread_to_pid(thread),SIGSTOP);
> > 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. > > How do you want to redirect? The kernel does not provide this > functionality. Again, if I call > > kill (ID_of_the_process, SIG) > > the implementation has to > > - look whether there is any thread waiting for this signal (sigwait); > if yes, deliver it
We cache that information in our shared address space by wrapping sigwait. We then use kill or sigqueue to have the kernel deliver it to the right target.
> - see if there is none, see whether any thread is not blocking it; if yes > devliver it
Cache that information by wrapping signal and sigqueue
> - see if there is any thread non ignoring the signal; in this case the signal > has to be cured to be eventually get delivered to the next thread > unblocking the signal or to be discarded if the last threads marks the > signals as to be ignored
See above
> > - otherwise call threads ignore the signal and it has to be discarded
... Am I missing something here?
> There must be a central handling of the signals. Either in active > form (= manager) or in passive form as with the shared signal queue. > I very much prefer the shared signal queue since it also can handle > SIGSTOP/SIGCONT.
It would still be active, but in the kernel instead of in user space. Thus, every program would pay a price for Pthreads, whether it used it or not.
> > -- > ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace > Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA > Red Hat `--' drepper at redhat.com `------------------------
-- --------------------------------------------------------- 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/
| |