Ceri Storey <cez@necrofish.org.uk> writes:

> I don't suppose there's been any advancement on this subject, that is,
> that runtime loading of libpthread into a non-threaded application
> causes functions which rely on the libc thread-stubs (eg: malloc) to
> break?

There has not been any progress, because this isn't considered a
serious problem. It's pretty much a "don't do that!" situation.

> I'd have expected that the new strongly aliased thread_stubs from
> libpthread would be used to override the weakly aliased ones from libc.
> However, this doesn't seem to be being done.

The reason that that doesn't work is that the binding between an
application/library's use of some routine (say, pthread_mutex_lock(), or
one of the cancellation-point syscalls like write() or read()) is
established the first time that the symbol is used (or at program
startup with LD_BIND_NOW set). There isn't a way for libpthread to
change that binding once it is established. This can lead to badness
like locking a mutex with a dummy pthread_mutex_lock() and then trying
to unlock it with the real pthread_mutex_unlock(). 

> Is this to avoid fun problems such as one function which expects the
> data to be laid out one way to be called with data laid out another way?
> (Eg: like when you find you've got two differing versions of a library
> loaded into a process). Or is it just technically infeasible?

As Martin mentioned, it could be done, by adding some explicit
indirection from non-threaded to threaded code in libc, but it would
add unnecessary overhead to programs which don't use threads at all.

Is there a particular application you're encountering that requires
this? I would say that the general philosophy for libraries that want
to be thread-safe but not create their own threads is to use the
thread.h cpp indirection layer and then let the application's use or
non-use of threads drive the binding of those routines.

        - Nathan