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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100705171251.gb18...@roeckx.be
