Subject: Re: pthreads plan
To: Michael Graff <explorer@flame.org>
From: Greg Hudson <ghudson@MIT.EDU>
List: tech-userlevel
Date: 11/06/1999 10:44:45
> Create thread-safe versions of most of libc.  I don't know how I'd
> like to do this exactly.  Some systems create libc_r, but I think we
> can have one libc, but if you compile a header with _REENTRANT, you
> get MT-safe versions, and perhaps warnings about non-MT safe bits.

If possible, it would be really neat to avoid the situation where
there are threaded objects and non-threaded objects, and never the
twain shall meet.  When I was involved in MIT pthreads development, a
lot of users wanted to be able to link in non-thread-safe code and
wrap locks around them for safety, and requiring to recompile that
code with special headers or a special define was often too high of a
bar.

I think the major sticking point is getc() and putc(), which need to
be (a) fast in normal programs, and (b) MT-safe in pthreads programs.
You can get the overhead for normal programs down to a single
condition check by introducing a global flag which gets set when the
first thread is created.

Incidentally, MIT pthreads took the approach of making many
non-reentrant libc functions use thread-specific data; e.g. getpwnam()
would return its result in a thread-specific buffer so that multiple
threads can use it.  That's not required by POSIX, so it can be
punted if it makes life easier.