Messages in this thread | | | Date | Tue, 28 Mar 2000 13:00:29 -0700 | From | yodaiken@fsmlabs ... | Subject | Re: Slow pthread_create() under high load |
| |
On Tue, Mar 28, 2000 at 11:41:19AM -0800, Ulrich Drepper wrote: > yodaiken@fsmlabs.com writes: > > > So the nonmanager threads do > > sigaction(n,s) > > === save local copy of s,n,thread_id > > real_sigaction(realprocessid(myid)); > > if unblocked a signal that is user_space pending > > kill self with that signal > > > > Now the information about who blocks what is available in user space > > > > kill(gettpid(),n) where gettpid has been fixed to get the > > root pid > > === find someone who is not blocking and > > kill(someone,n) > > if all threads block, then mark signal > > as pending > > You are completely neglecting that the signals are not coming alone: > > - there is a signal context. If the process which receives the signal > first (mainly the manager) simply returns the signal context on its > stack is lost.
Perhaps I'm missing something, but my idea was that the manager would not be sent any signals by other threads.
> Copying it means garbage collection of some kind
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.
> - you have to handle certain signal special (segfault, stop/continue). > Especially the later contains the possibility for arbitrary many > races if not done in the kernel.
But the POSIX standard permits such races -- no?
> - RT signals have to transport data which, again, can be in the signal stack. > > - sigaltstack must continue to work
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. The race potential is only when thread A is concurrently blocking signal N while thread B is trying to send it and selected A as the destination. But that seems solvable.
> > > I'm cutting it short here. > > -- > ---------------. 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/
| |