[lkml]   [2000]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Slow pthread_create() under high load
On Tue, Mar 28, 2000 at 04:27:42PM -0800, Ulrich Drepper wrote:
> 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 ,-. 1325 Chesapeake Terrace
> Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
> Red Hat `--' drepper at `------------------------

Victor Yodaiken
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
Please read the FAQ at

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