This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: Slow pthread_create() under high load
- To: Ulrich Drepper <drepper at cygnus dot com>
- Subject: Re: Slow pthread_create() under high load
- From: Alvin Starr <alvin at iplink dot net>
- Date: Mon, 27 Mar 2000 00:51:05 -0500 (EST)
- cc: sasha at mysql dot com, Kaz Kylheku <kaz at ashi dot footprints dot net>, glibc-linux at ricardo dot ecn dot wfu dot edu, linux-kernel at vger dot rutgers dot edu, mysql at lists dot mysql dot com, monty at mysql dot com
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
On 25 Mar 2000, Ulrich Drepper wrote:
> sasha@mysql.com writes:
>
> > My guess is that clone() should return very fast to the original thread, but
> > might take a while to return to the newly created thread, which is what is
> > causing the problem.
>
> The kernel does not allow using clone() directly because some
> additional functionality required to implement the correct POSIX
> threads behaviour is missing. Do you think we make these things slow
> on purpose?
there is a saying I like:
" Never attribute to malice that which can be adquatly explained by
incompatence. "
> If you want to see this changes get the kernel changes in place.
> There are various patches floating around which combined will allow a
> correct and fast implementation. But they were not added.
Any special reason they were not added?
Do you have a list of these patches?
I am sure that if the next version of the thread library required a set of
kernel patches to run effectivly then those patches would end up in the
kernel source tree within a version or so.
Alvin Starr || voice: (416)585-9971
Interlink Connectivity || fax: (416)585-9974
alvin@iplink.net ||