lkml.org 
[lkml]   [2000]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Slow pthread_create() under high load
From
Date
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > Alan, if POSIX threads are a "braindamaged pile of crap" (not arguing
> > but I do use threads quite heavily) what would you rather us use as
> > threads in Linux? Or are you not happy with any current implementation?
>
> If you want performance use clone() directly. If you want portability
> you have to pay for the glue. Ulrich is right that at the moment said glue
> involves jumping through a few too many hoops

I can see the reasons for using clone() directly in some cases, but
currently there are several obstacles which make it a last resort:

- Most programs needs a lot of the functionality provided by
LinuxThreads (basic synchronisation primitives, stack allocation),
even if they don't need the pthreads API itself.

- glibc hooks into linuxthreads for thread safety

- The gdb LinuxThreads support depends upon the internals of
LinuxThreads (that support isn't wonderful, but it is better than
nothing).


So it would be nice if LinuxThreads offered two interfaces:

1) A simple interface to the pthreads-independent stuff.

2) The pthreads API, with all of the hoop-jumping that implies.


(1) could be used by programs directly, or could be used to implement
other threads APIs (or by other language implementations).

It would be good if the interface for (1) avoided tying down its
implementation too much. For instance, someone could add two-level
thread support to it to distract certain Java implementors from their
attempts to "improve" the kernel's scheduler.


David Wragg

-
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.142 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site