Date: Thu, 07 Dec 2000 21:55:07 +0000 From: Brian Somers <brian@Awfulhak.org> To: Daniel Eischen <eischen@vigrid.com> Cc: Brian Somers <brian@Awfulhak.org>, "Jacques A. Vidrine" <n@nectar.com>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Threads in the base system Message-ID: <200012072155.eB7Lt7G51311@hak.lan.Awfulhak.org> In-Reply-To: Message from Daniel Eischen <eischen@vigrid.com> of "Wed, 06 Dec 2000 22:03:25 EST." <Pine.SUN.3.91.1001206213644.25911A-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012072155.eB7Lt7G51311>