Date: Wed, 6 Dec 2000 22:03:25 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Brian Somers <brian@Awfulhak.org> Cc: "Jacques A. Vidrine" <n@nectar.com>, Brian Somers <brian@Awfulhak.org>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG Subject: Re: Threads in the base system Message-ID: <Pine.SUN.3.91.1001206213644.25911A-100000@pcnet1.pcnet.com> In-Reply-To: <200012062321.eB6NLlt08622@hak.lan.Awfulhak.org>
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? -- Dan Eischen 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?Pine.SUN.3.91.1001206213644.25911A-100000>