Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Sep 2003 09:22:11 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Scott Long <scottl@freebsd.org>
Cc:        Freebsd Current <current@freebsd.org>
Subject:   Re: Fixing -pthreads (Re: ports and -current)
Message-ID:  <Pine.NEB.3.96L.1030924091657.60986D-100000@fledge.watson.org>
In-Reply-To: <3F71396A.6070508@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 24 Sep 2003, Scott Long wrote:

> I'm a big advocate of using libmap to deal with this.

Ditto.

Based on the results seen thus far, my preference would really be for:

(1) Keep -pthread, make it imply -lpthread, saving a lot of hassle.

(2) Ship all packages and binaries using threading with -lpthread -- i.e.,
    a dynamic library dependency on libpthread.  This will mean that
    administrators don't have to list each possible threading library in
    /etc/libmap.conf in order to be sure they caught all of them.

(3) Use libmap to perform the necessary substitution on a per-application
    or per-system basis.  If libpthread isn't available on an
    architecture, default ship libmap.conf to substitute libthr for
    libpthread on the platform for all applications.  Or libc_r, or
    whatever.

This will result in all applications we ship having a consistent thread
library name so that administrators can substitute more easily. libpthread
would give you M:N threading by default, but it would be easy to perform
local changes to improve performance for applications that specifically
benefit from 1:1 threading, cothreads, etc.  Or if a serious compatibility
bug is found between libpthread and an application, they can substitute
easily as well.  I suppose this case might imply (4):

(4) If an application is known to be compatible only with a specific
    threading model, do hard-code that in the application build somehow.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Network Associates Laboratories





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030924091657.60986D-100000>