Subject: Pthreads, libc, and the future
To: None <tech-userlevel@netbsd.org>
From: Michael Graff <explorer@flame.org>
List: tech-userlevel
Date: 12/10/1999 15:44:12
So, the ultimate goal is to use scheduler activations (or the like)
for userland/kernel threads.  However, in the short-term, I'd like to
get 1.5 shipping with threads.

Along those lines, I'd like to import the code I've been working on,
which is based on MIT pthreads.  Yes, I know they're not perfect, but
they work, and they are the easiest to import at this stage.

I'd like to do this ASAP -- this weekend if possible.  The issues are:

(1)  Not all architectures are currently supported.  I have code for
     and can test on i386, arm32, while the m68k, alpha, and sparc
     code I cannot test even though I have it.

(2)  libc should be finished off as a thread-safe library, using
     _REENTRANT as the que.  To do that, pthread.h (or, more
     specifically, the definitions of locks and such) needs to be
     present.  This means two things:

	(a)  Changing the threads interface in a major way might
	require a libc version bump, or at the least a synchronized
	update of libpthread.so and libc.so.

	(b)  It will tie us down to one specific implementation of
	threads.  Since it includes our installed pthreads.h file,
	another implementation will _not_ work in its place, unless
	libc is compiled using its pthread.h file.

Considering the timeline for 1.5, and that bind9 currently _requires_
threads (as do many other packages) I think we need to have pthreads
in 1.5, even if they are not perfect.

--Michael