From owner-freebsd-current@FreeBSD.ORG Wed Sep 24 08:27:32 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 2104A16A50E; Wed, 24 Sep 2003 08:27:32 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD86D43FF9; Wed, 24 Sep 2003 08:27:30 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 6098D54885; Wed, 24 Sep 2003 10:27:30 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id F34856D454; Wed, 24 Sep 2003 10:27:29 -0500 (CDT) Date: Wed, 24 Sep 2003 10:27:29 -0500 From: "Jacques A. Vidrine" To: deischen@freebsd.org Message-ID: <20030924152729.GC57702@madman.celabo.org> References: <3F71396A.6070508@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 cc: Doug Barton cc: Freebsd Current 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 15:27:33 -0000 [Mostly trying to stay out of this thread, but I must comment at least on this point.] On Wed, Sep 24, 2003 at 11:01:01AM -0400, Daniel Eischen wrote: > On Wed, 24 Sep 2003, Scott Long wrote: > > Daniel Eischen wrote: > > > o Allows shared libraries (Qt, GTK, OpenGL, etc) to be built that > > > are not dependent on a particular threads library, but will use > > > whatever threads library the application uses (i.e., you want mplayer > > > to use libpthread and ogle to use libthr). > > > > I'm a big advocate of using libmap to deal with this. > > It isn't clear that libmap can deal with libraries that are > linked to one specific threads library, and how libmap'd > applications work. If mplayer is libmap'd to libthr, > ogle is libmap'd to libpthread, and both are linked to > libGL which is linked to libc_r, what happens? > > At the least, -pthread should be a NOOP when building > shared and dynamic. While libmap is a very neat hack and very useful, it is indeed a hack and I do not think it should be the primary method of determining what libraries to load. The mere existance of a libmap.conf file means additional file opening and parsing every time a dynamically linked executable is loaded; as well as one or more string searches/substitutions for every dynamic object name that rtld encounters (not just thread libraries). I believe that we should be able to make decisions at link time and at run time. At link time, either (a) I want *this* threaded library damnit, or (b) choose a threaded library at run time, with (b) being the default. Choosing (a) probably allows you to shoot your foot by mixing threading libraries, but it may also allow you to use `extensions' that one threading library might provide but not another. At run time (if (b) was chosen at link time): use *this* threaded library. By what mechanism? I imagined that there could be a library (say libpthread :-P) that made the decision and loaded the *real* threading library and forwarded or fixed-up thread-related functions. A degenerate-but-simple implementation might be a symlink. This seems to be more-or-less what GCC developer Loren James Rittle had in mind when he posted the following suggestion to freebsd-threads some weeks back: Thank you for considering these words. BTW, wouldn't it be cooler if (example only): -pthread (whatever the system default) -pthread=1 (1 process, aka -lc_r) -pthread=1:1 (1 process per thread, aka -lthr) -pthread=M:N (M threads in N processes, aka -lkse) -pthread=late/weak (perhaps not good ELF form, link against a stub to which all POSIX thread libraries on FreeBSD must conform, do not record the dependency ala FreeBSD4 default for -lc; or that does it in a weak manner en mass such that binding is deferred to the final selection made at a final link time) Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal nectar@celabo.org . jvidrine@verio.net . nectar@freebsd.org . nectar@kth.se