Eric Haszlakiewicz <erh@nimenees.com> writes:

> On Wed, Nov 24, 2004 at 11:15:19PM -0500, Nathan J. Williams wrote:
> > Bill Studenmund <wrstuden@netbsd.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)

http://mail-index.netbsd.org/tech-userlevel/2004/11/23/0000.html

(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.

        - Nathan