Bug#475101: obsolete linuxthreads requirement
On Mon, Jul 05, 2010 at 10:20:43AM +0200, Simon Josefsson wrote:
>
> Hm. There is a small risk that the above will be interpreted to mean
> that e.g. pthreads should be enabled if supported by the library, but
> that is not always the best solution -- consider if a library supports
> native linking to pthreads, nptl, GNU Pth, or no thread library but
> require the application to provide mutex callbacks. (We are actually
> considering something like that for GnuTLS now, so it is not entirely
> hypothetical.) I would argue that the best for debian would be to build
> the library in the last configuration. Or can we declare that Debian
> only supports one thread package? The problem, of course, is that some
> applications will be using pthreads and some will use nptl, and linking
> libraries that are hard-coded to use pthreads (or nptl) will not work
> well.
The current situation with openssl is that they provide callback
mechanisms for that. And it really doesn't seem to be working
very well for them. The problem is that both libraries using
openssl and applications using it should be setting them, and it
might end up linking to openssl directly and indirectly and ends
in a mess. It's one of the topics that regurarly come back.
Linux threads and NPTL both provide the POSIX API to do threads
and both use "-lpthread", it's just the internal implementation
of the library that is different. libpth on the other hand
seems to be having it's own API, so you also link to an other
library.
Anyway, there is a difference between a library being thread safe,
which is what we want, and a library creating it's own threads.
To be thread safe you can use various ways, but it includes
synchronisation objects, and how you do that isn't really
important. And some people will argue that the application making
use of the library will know what the best type is, and so will
prefer a callback mechanism. It also makes sure there is no
overhead in case no threads are being used. But on the other
hand it's very handy that a library sets this up itself without
the applications needing to care.
Kurt
Reply to: