Subject: Re: pthreads plan
To: Greg Hudson <ghudson@MIT.EDU>
From: Michael Graff <firstname.lastname@example.org>
Date: 11/06/1999 08:25:01
Greg Hudson <ghudson@MIT.EDU> writes:
> 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.
What about something like this?
_getc(): no multithreaded support
and in the header file:
The purpose is to make getc() do locking only when needed. BTW, if
the mutex locking code can be made at least partially inline, and only
call a function in the failure case, I think life would be much better
for speed, and perhaps the locking overhead could just be ignored.
> 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.
It would be punted initially at least.