Subject: Re: Pthreads, libc, and the future
To: Jason Thorpe <firstname.lastname@example.org>
From: Bill Sommerfeld <email@example.com>
Date: 12/11/1999 09:15:17
> You have this exactly backwards.
> First, identify the dependencies which you think libc would have on
> the pthreads implementation. One such dependency is locks.
> 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.