This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Slow pthread_create() under high load


[My, my, how the Cc list has grown]

Albert D. Cahalan writes:
> Richard Gooch:
> > You could probably write a native Linux threads library (lthread_*()
> > anyone?) which was just as easy to use and powerful, and didn't
> > require buggering the kernel. So from the point of view of the
> > kernel community, there is reluctance to throw complex and ugly
> > POSIX-specific support code into the kernel, for the sake of
> > compliance with an ill-considered standard. Leave the problems to
> > user-space, and hence the performance problems people mention.
> 
> If you have no problems with embrace-and-extend, yes.

No, that's not a fair comment. Just as we have added a more efficient
I/O event mechanism than select(2)/poll(2) (the sigio stuff), there is
no reason not to add other mechanisms which are more efficient than
the "standard". They will be open and documented, so everyone is free
to implement them too. And lthreads would designed to have an almost
identical API to pthreads, so a few macros would probably suffice to
port from one to the other.

We shouldn't create new API's for the hell of it, or to bugger our
"competition". But neither can we allow poor standards to tie our
hands.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]