Date: Tue, 8 Jun 2004 13:01:32 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: weak implementation of threads has problems - kse fix attached Message-ID: <Pine.GSO.4.10.10406081251510.2107-100000@pcnet5.pcnet.com> In-Reply-To: <20040608154510.GB89198@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Jun 2004, Dan Nelson wrote:
> In the last episode (Jun 08), Kris Kennaway said:
> > On Mon, Jun 07, 2004 at 11:48:45PM -0500, Dan Nelson wrote:
> > > In the last episode (Jun 08), Daniel Eischen said:
> > > > No, I don't want to litter all our thread libraries with strong
> > > > references. As I've said before, build your shared libraries
> > > > correctly so they don't bring in the threads library.
> > >
> > > A good addition to bsd.port.mk, right next to the "possible network
> > > server" etc checks, might be to run ldd on all installed shared
> > > libraries and print a warning if any threads libraries show up. There
> > > are a huge number of ports that install shlibs linked to libpthreads.
> >
> > Some of these are probably correct, in that the library started using
> > libpthreads internally and there are a large number of clients that
> > would otherwise need to be changed to link to that library.
>
> I don't think you can have it both ways, though. The rule is either
> "pthreads-using shared libraries should pull in a pthreads lib
> themselves" or "programs wanting to link to pthreads-using shared
> libraries should link with a pthreads lib".
I think there are two cases as I outlined earlier in this
thread:
a) libraries use pthread_foo() for thread-safety
b) libraries use pthread_create() & pthread_foo()
to create and manage threads on behalf of the
application (e.g, an AIO library).
I doubt there are many, if any, of b). If there are,
you should require that all applications that use b)
also link to the threads library (which makes sense
because they are then threaded). For a), applications
can choose to link with the threads library or not,
and it doesn't matter at all that the shared library
is not linked to the threads library.
Also for b), if the library is not linked to the
threads library and the application using b) also
does not link to the threads library, then you get
a link error for the application (missing pthread_foo
symbols). It should be immediately obvious when
building the port what happened.
Another advantage of not linking shared libraries to
a threads library is that it becomes much easier to
tailor a libmap.conf on per-application basis. You
no longer have to worry about shared libraries bringing
in a different thread library.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10406081251510.2107-100000>