On Wed, Nov 24, 2004 at 10:22:10AM -0800, Bill Studenmund wrote:
> On Wed, Nov 24, 2004 at 07:27:23PM +0200, Arto Huusko wrote:
> > On Wed, 24 Nov 2004, Nathan J. Williams wrote:
> > Why only pthread_create()? I mean, how can a module be written
> > so that it can satisfy thread-safety in the presence of a
> > threaded app, without the module directly using pthread functions
> > such as mutexes etc.
> 
> I'm not sure how official it is, but libc uses "threadlib.h". You can
> include it and use "mutex_t" and "cond_t" and such. Then mutex_init(),
> mutex_lock(), cond_signal(), cond_broadcast() and friends. If libpthread
> is around, the calls map to pthread_ (pthread_mutex_lock(), 
> pthread_cond_signal(), etc.) calls. If libpthread isn't around, the calls 
> map to the "do nothing" calls in libc that started this thread.

	So the app needs to be rewritten to use the threadlib functions. ugh.
I thought that libc had weak aliases for the pthread functions, but I
just realized that it has weak aliases for it's own internal threading
functions instead. (why?)

	Could we have a define that turns the functions in pthread.h into 
aliases for those in threadlib.h?  That could make fixing modules that
currently link against pthread easier.  e.g.
gcc -DPTHREAD_THREADLIB foo.c
would cause #include <pthread.h> in foo.c to do
#include <threadlib.h>
#define pthread_mutex_lock(m) mutex_lock(m)
etc..., instead of the normal function prototypes.
(leaving pthread_create() undefined to catch errors)

eric