From owner-freebsd-current@FreeBSD.ORG Tue Sep 23 23:28:13 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 2F7B316A4B3 for ; Tue, 23 Sep 2003 23:28:13 -0700 (PDT) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 0C38543FFB for ; Tue, 23 Sep 2003 23:28:10 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: (qmail 41297 invoked by uid 1002); 24 Sep 2003 06:28:08 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 24 Sep 2003 06:28:08 -0000 Message-ID: <3F71396A.6070508@freebsd.org> Date: Wed, 24 Sep 2003 00:27:54 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: deischen@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 06:28:13 -0000 Daniel Eischen wrote: > On Tue, 23 Sep 2003, David Schwartz wrote: > > >>>On Mon, 22 Sep 2003, David Schwartz wrote: >> >>>No. There are other environments that don't have -pthread >>>though. >> >> So now FreeBSD will support a flag that numerous other platforms support, >>however it will support it differently from every other platform. On every >>other platform I know of where '-pthread' does anything other than generate >>an error, it causes the compiler to conform to the pthreads standard. >>FreeBSD will be the only platform that knows what '-pthread' is but doesn't >>do the right thing when it gets it. >> >> Isn't it good to have one flag that, on every platform that supports it, >>gives you whatever's needed to get the default pthreads implementation to >>work? And isn't that what '-pthread' was supposed to be for? >> >> >>>Why do you want to shoehorn -pthread onto us when it is not >>>a good fit? >> >> Then don't support it. Return an error and nothing will break. > > > You have the support of the threads guys here, including jb. But > we've been pushed the other way. > > >>However, I'd >>also suggest making it easy for people to set '-pthread' to give whatever >>pthreads library they think is the most sensible default for their >>installation. > > > You can't make it variable. > > I'm running out of energy here. None of the threads guys want -pthread > and if forced on them would prefer it to be a NOOP. I am trying very > hard not to be biased towards one threads library over another, and > having -pthread automatically link to libpthread gives preference to > it over libthr (or libthread (KSE in 1:1 mode) or libc_r). > > Pros: > o Allows us to define macros common to all the threads libraries. > 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. > o If we support LD_PRELOAD properly, will allow us to select the > threads library without having to rebuild/relink the application. I'm a big advocate of using libmap to deal with this. > o Doesn't break applications that use both -pthread and -l. > We've been able to link both libc_r and libc in -current for well > over 2 years. Indeed, if you build KDE and X with libpthread installed, > you will see binaries that are linked to both libc_r and libpthread. I can't see how this behaviour would not be considered a bug, if it is indeed true. Are you saying that there are packages out there that will detect both -lpthread and -pthread and attempt to use both on the compilers and linker lines? > o Makes it easier to spot ports that are not PTHREAD_LIBS compliant. PTHREAD_LIBS is a great tool for the /usr/ports mechanism, but doesn't mean anything outside of that. I suspect that the majority of users won't give a hoot about the mechanics of all of this as long as it Just Works. The more sophisticated users that want to mix/match threading libraries can be expected to exert a little more effort and learn the tools like libmap, etc. > > Cons: > o Third party applications that use -pthread exclusively (without > linking to a threads library) will have to add a link option. This is where I have the biggest problem. I firmly believe that it is incorrect for you to downplay this scenario, and it appears that others agree too. This is the case that will give us the black eye with users and developers that want things to Just Work. > > I understand that folks want to wave their hands and say "just make > -pthread work and do whatever it needs to". I'm like that myself. > I just don't think it's a good idea. > I'm unclear why it is impossible to do this. The whole point of -pthread is to make it Just Work. We have complete control over how we make that happen. Why is it impossible to make -pthread honor PTHREAD_LIBS? Why is it impossible to fix ports that try to mix pthread schemas? Scott