[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
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:23 EST