Subject: Re: Threading problems
To: Eric Haszlakiewicz <email@example.com>
From: Nathan J. Williams <firstname.lastname@example.org>
Date: 11/24/2004 23:44:32
Eric Haszlakiewicz <email@example.com> writes:
> On Wed, Nov 24, 2004 at 11:15:19PM -0500, Nathan J. Williams wrote:
> > Bill Studenmund <firstname.lastname@example.org> writes:
> > > I don't think that'd be a good idea. If you're using pthread.h, you're
> > > using libpthread, not threadlib.
> > threadlib.h is a bad hack. Why the "obvious" solution I suggested
> > yesterday didn't occur to any of us when I did this in the first place
> > isn't clear to me, but I'm in favor if implementing it and causing
> > threadlib.h a swift death.
> I must have missed it. What's the "obvious" solution?
> (I don't see it in the mail-index archives either)
(this conversation has drifted around a few different lists)
Restating, in pthread.h:
#define pthread_mutex_lock(x) __libc_mutex_lock(x)
#define pthread_mutex_unlock(x) __libc_mutex_unlock(x)
and so on. Notably, no such #define for pthread_create().
* Libraries that want data protection only will not need to link
against libpthread. They'll get real mutexes when there are threads
and no-ops when there aren't (strictly speaking, when libpthread
isn't linked in)
* Libraries or applications that genuinely use threads will fail to
link because pthread_create() and other non-defensive functions are
missing; it'll be obvious to add -lpthread.
* <threadlib.h> dies.