From owner-freebsd-arch Thu Dec 7 13:54:29 2000 From owner-freebsd-arch@FreeBSD.ORG Thu Dec 7 13:54:26 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from Awfulhak.org (awfulhak.demon.co.uk [194.222.196.252]) by hub.freebsd.org (Postfix) with ESMTP id 9339A37B401; Thu, 7 Dec 2000 13:54:24 -0800 (PST) Received: from hak.lan.Awfulhak.org (root@hak.lan.awfulhak.org [172.16.0.12]) by Awfulhak.org (8.11.1/8.11.1) with ESMTP id eB7LqZx24603; Thu, 7 Dec 2000 21:52:35 GMT (envelope-from brian@lan.awfulhak.org) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.11.1/8.11.1) with ESMTP id eB7Lt7G51311; Thu, 7 Dec 2000 21:55:07 GMT (envelope-from brian@hak.lan.Awfulhak.org) Message-Id: <200012072155.eB7Lt7G51311@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Daniel Eischen Cc: Brian Somers , "Jacques A. Vidrine" , Robert Watson , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Threads in the base system In-Reply-To: Message from Daniel Eischen of "Wed, 06 Dec 2000 22:03:25 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Dec 2000 21:55:07 +0000 From: Brian Somers Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Wed, 6 Dec 2000, Brian Somers wrote: > > > On Wed, Dec 06, 2000 at 04:50:29PM -0500, Daniel Eischen wrote: > > > > I was just [re]thinking about this. When we get libpthread (work > > > > has just started on this), then libc_r will eventually go away. > > > > It's not clear yet whether libpthread will exist as a separate > > > > entity or whether it will evolve from libc_r. > > > > > > For the ignorant (me), what is/will be the difference between libc_r and > > > libpthread? > > > > And me ! > > OK, libc_r is libc + threads; an application can't be linked to both > libc_r and libc. libpthread is just the thread routines (at least > those that aren't included in libc) and _is_ linked with libc. When > you have libpthread, the gcc option "-pthread" goes away (which we use > to link to libc_r and prevent linking to libc), and you link with > "-lpthread". In theory, libc_r could be an archive of libc and > libpthread. > > We may want to keep libc_r around for a while for compatibility > reasons (without moving it to compat). But at some point, libc_r > will cease to be built the way it is currently being built (to > include libc). All the _THREAD_SAFE checks will be removed from > libc. Instead, libc will contain stub routines for the needed > lock operations. These will be weak symbols that will be overloaded > with (non-weak symbol) routines of the same name in libpthread. > When libpthread isn't linked in, then the null stub routines > will be invoked. If libpthread is linked in, then the real lock > routines will be called. > > > Besides, can't we put libpthread in libc_r's place when it goes away ? > > Yes, but it can't be used (linked to) the same way nor named the > same. > > I guess my point is that applications in our base system that > require threads will need !NOLIBC_R || !NOLIBPTHREAD. And NOLIBC_R > will eventually become the default some time after libpthread gets > integrated. > > It's a little confusing, but am I making sense? Yes. I'd tend to just say that we do it in these stages: 1. Remove NOLIBC_R 2. Eventually introduce libpthread 3. Change all Makefiles that say -pthread to say -lpthread 4. Blow away libc_r With whatever gap is required between each step. We *could* replace item 1 with ``don't build -pthread programs if NOLIBC_R'' and change that to NOLIBPTHREAD when item 3 is done, but I'd say it's better to encourage threads and not give these options. > -- > Dan Eischen -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message