> You have this exactly backwards.
> 
> First, identify the dependencies which you think libc would have on
> the pthreads implementation.  One such dependency is locks.

Right..

> What we should do here, instead, is provide those primitives in our
> libc, and then make the pthreads package build on top of those!

Including some sort of atomic test-and-set primitive in libc for use
by various packages which need one would be good.  i don't think you
can do much more than that.

Pthreads locks are tied fairly closely to the pthreads scheduler -- in
particular, condition variables and mutexes are pretty closely
associated, and an efficient pthreads scheduler would want to know
what mutexes and conditions a thread is waiting.

Perhaps _REENTRANT libc locking could be coded to a run-time
replaceable interface, and ports of various threading packages to run
with the reentrant libc could supply a vector of
lock/unlock/... operations.  Not the most efficient, but it doesn't
prematurely commit us to one particular threading package..

> I think there hasn't been enough thought put into this, so I would
> think importing it any time soon (especially this weekend!) would be
> a serious mistake.

I agree, more review is needed.

						- Bill