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: sinisa at mysql dot com
- Subject: Re: Slow pthread_create() under high load
- From: "Stephen C. Tweedie" <sct at redhat dot com>
- Date: Mon, 27 Mar 2000 12:29:01 +0100
- Cc: sasha at mysql dot com, alan at lxorguk dot ukuu dot org dot uk, drepper at cygnus dot com, 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, Stephen Tweedie <sct at redhat dot com>
- References: <E12YyOa-0004CY-00@the-village.bc.nu> <38DCD6AA.14654E21@mysql.com> <14557.59271.23249.524272@localhost.localdomain>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
Hi,
On Sun, Mar 26, 2000 at 01:33:43PM +0300, sinisa@mysql.com wrote:
>
> I understood (or misunderstood) Mr. Cox notes that when a new thread
> is created, scheduler goes through all existing threads and changes
> their time slice / priority , in order to accomodate a new thread in a
> fair manner.
No, not at all. Only the parent and child are involved in the fork
itself, although we may have to consider the priority of other runnable
tasks when we first come to scheduled the child.
> Regarding POSIX threads being "braindamaged pile of crap", it is
> unfortunately the only available standard for writing relatively
> platform - independent multithreaded servers.
Maybe, but although a lot of the POSIX threads are reasonable, things
like requiring uid/gid updates to be instantly effective across all
threads in the process are just insane. There ain't no way that's
going into the kernel any time soon: it would require adding semaphore
locking to all of the credential information that is currently task-
local.
--Stephen