Subject: Re: Threading problems
To: Bill Studenmund <firstname.lastname@example.org>
From: Eric Haszlakiewicz <email@example.com>
Date: 11/24/2004 16:03:44
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
#define pthread_mutex_lock(m) mutex_lock(m)
etc..., instead of the normal function prototypes.
(leaving pthread_create() undefined to catch errors)