Date: Wed, 6 Dec 2000 16:50:29 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Brian Somers <brian@Awfulhak.org> Cc: Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Threads in the base system Message-ID: <Pine.SUN.3.91.1001206164314.13505A-100000@pcnet1.pcnet.com> In-Reply-To: <200012062138.eB6Lc6t07375@hak.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1001206164314.13505A-100000>