"Nathan J. Williams" <nathanw@wasabisystems.com> writes:

> Right, that's what I meant by "inappropriately". If the goal is to be
> a library that is safe in the presence of threaded calling code, then
> linking against libpthread is the wrong answer. The right answer is to
> use our <threadlib.h> routines, and let the libc weak-binding work for
> you, rather than against you.

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() [that those names are used in libc is
something of a historical accident involving the import of Sun code
before pthreads were firmly entrenched as the only real thread
interface].

Notably, only routines that make sense as safe no-ops should get this
treatment; if a program tries to call pthread_create(), it should only
get the real thing, and throw a linking error if libpthread is
missing.

The real linkage names need to stick around too, of course... does
anyone see problems with this plan?

        - Nathan