jdolecek@NetBSD.org (Jaromir Dolecek) writes:

> Nathan J. Williams wrote:
> > Thinking about this more, a better answer might be for <pthread.h> to
> > #define pthread_mutex_lock(x) to __libc_mutex_lock(x), so that ~all
> > code that is written to use locking routines from pthread.h will go
> > through the libc redirection by default, instead of making them
> > rewrite to mutex_lock()
> 
> Yes, this looks as a good solution - better than <threadlib.h>,
> which would require explicit patches to all software. Second
> necessary part is to change all packages so that no library is ever
> explicitly linked against libpthread. This could even be quite
> easily accomplishable by hacking libtool to filter -pthread on
> final library link.

Well, it *is* possible for a library to want to use threads directly,
for example to create a thread to perform operations "in the
background" of the calling app. This shouldn't be disallowed, even
though it's uncommon.

        - Nathan