From owner-freebsd-arch Wed Dec 6 13:51: 1 2000 From owner-freebsd-arch@FreeBSD.ORG Wed Dec 6 13:50:58 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 78C1337B400; Wed, 6 Dec 2000 13:50:57 -0800 (PST) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA14771; Wed, 6 Dec 2000 16:50:30 -0500 (EST) Date: Wed, 6 Dec 2000 16:50:29 -0500 (EST) From: Daniel Eischen To: Brian Somers Cc: Robert Watson , freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Threads in the base system In-Reply-To: <200012062138.eB6Lc6t07375@hak.lan.Awfulhak.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 6 Dec 2000, Brian Somers wrote: > Good spot. I believe NOLIBC_R should/must go. 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. It's possible that NOLIBC_R might actually become the default. > > Recently, pppctl was made thread-enabled, meaning that it relies on > > libc_r. This makes the NOLIBC_R cannot be used with buildworld anymore. > > Given that making pppctl depend on !NOLIBC_R may not be all that helpful, > > it looks like we may need to lose NOLIBC_R. Presumably over time, threads > > in default system applications will only become more popular. Any > > thoughts (especially in light of upcoming KSE changes, which will make > > threading integral to the system architecture)? > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > > robert@fledge.watson.org NAI Labs, Safeport Network Services -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message