Re: Slow pthread_create() under high load

From: yodaiken@fsmlabs.com
Date: Tue Mar 28 2000 - 20:02:41 EST


On Tue, Mar 28, 2000 at 04:27:42PM -0800, Ulrich Drepper wrote:
> yodaiken@fsmlabs.com writes:
>
> > 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.
>
> No. I've told you their is the signal context, data to transport and
> whatever. This is not so easy. All your explanation of how you can
> make it work depends on sending only the signal itself, without
> additional information. This is not what is expected.

I don't understand why we can't also send the remaining information using
sigqueue. What specific information is missing?
The manager gets a siqnal sent via kill: resend using kill.
The manager gets a signal sent via sigqueue: resend via sigqueue

> > 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);
>
> When did you receive SIGSTOP at the user level? This is a signal
> processed in the kernel.

Good point. POSIX semantics on this issue seem to forbid a user level
solution. The problem can be handled for internal threads, but
not when an external process sends SIGSTOP to a threaded process.
I give up on this one.

> > 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.
>
> This completely depends on the implementation. You certainly can hide
> the use of the shared signal queue which is not needed if your are not
> using clone().
>
> --
> ---------------. 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/



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:23 EST