From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 07:27:24 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F018B16A582 for ; Wed, 24 Sep 2003 07:27:24 -0700 (PDT) Received: from thuis.piwebs.com (217-19-20-186.dsl.cambrium.nl [217.19.20.186]) by mx1.FreeBSD.org (Postfix) with SMTP id 41D0143FD7 for ; Wed, 24 Sep 2003 07:27:20 -0700 (PDT) (envelope-from freebsd-current@piwebs.com) Received: (qmail 69527 invoked by uid 85); 24 Sep 2003 14:27:40 -0000 Received: from freebsd-current@piwebs.com by thuis.piwebs.com by uid 82 with qmail-scanner-1.20rc1 (uvscan: v4.2.40/v4288. Clear:RC:1:. Processed in 0.065119 secs); 24 Sep 2003 14:27:40 -0000 Received: from localhost (HELO piwebs.com) (127.0.0.1) by 0 with SMTP; 24 Sep 2003 14:27:39 -0000 Received: from 213.93.164.177 (SquirrelMail authenticated user freebsd-current@piwebs.com) by www.dynamicsolutions.nl with HTTP; Wed, 24 Sep 2003 16:27:39 +0200 (CEST) Message-ID: <20332.213.93.164.177.1064413659.squirrel@www.dynamicsolutions.nl> Date: Wed, 24 Sep 2003 16:27:39 +0200 (CEST) From: To: In-Reply-To: References: <3F71396A.6070508@freebsd.org> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.9) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: current@freebsd.org Subject: Re: Fixing -pthreads (Re: ports and -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2003 14:27:25 -0000 > > 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. This sounds to me like the best solution I've seen so far. We have libmap, so why not use it? Only expert users will probably want to play with different thread libraries, and they can find out about libmap.conf themselves. Arjan