From owner-freebsd-threads@FreeBSD.ORG Tue Jun 8 17:01:44 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BD5A16A4CE for ; Tue, 8 Jun 2004 17:01:44 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C090843D2F for ; Tue, 8 Jun 2004 17:01:43 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i58H1WPd005184; Tue, 8 Jun 2004 13:01:32 -0400 (EDT) Date: Tue, 8 Jun 2004 13:01:32 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dan Nelson In-Reply-To: <20040608154510.GB89198@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org cc: Sean McNeil cc: Kris Kennaway Subject: Re: weak implementation of threads has problems - kse fix attached X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2004 17:01:44 -0000 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