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 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.081 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site