Date: Tue, 25 Oct 2005 16:21:10 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-arch@freebsd.org Subject: Re: libc_r is deprecated Message-ID: <200510251621.10384.peter@wemm.org> In-Reply-To: <435E2DCF.6080809@freebsd.org> References: <Pine.GSO.4.43.0510241948130.17636-100000@sea.ntplx.net> <20051025120538.K52058@fledge.watson.org> <435E2DCF.6080809@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 25 October 2005 06:06 am, David Xu wrote: > Robert Watson wrote: > > On Mon, 24 Oct 2005, Daniel Eischen wrote: > >> On Tue, 25 Oct 2005, David Xu wrote: > >>> Folks, > >>> > >>> For years development, we now have libpthread and libthr, libc_r > >>> does not support SMP or multi-core processor, also it has many > >>> bugs (still in our bug database), also threads@ developers seems > >>> not have interest to maintain it, it is doomed, so I would like > >>> to disconnect it from buildworld, and sometimes later, I would > >>> like to remove it. > >> > >> Deprecate in 6.x and remove in 7.0? > >> > >> Someone might be able to make a port out of it also. > > > > I'd like to keep it around in some form -- I recently ran a series > > of HTTP-related benchmarks and libc_r benchmarked signicantly > > faster than other libraries on both UP and SMP. I'm working to > > refine the benchmark for improved realism, and will see if that > > persists. However, when it comes to understanding scheduling and > > threading behavior, I think libc_r remains useful... > > > > Robert N M Watson > > libc_r runs on single kernel thread, so if you are continue using > libc_r, you are not testing TCP/IP with multithreads program, this > may give you false data. Only kernel threads based server can test to > see if the TCP/IP stack locking works well. libc_r is also a useful metric to measure the relative costs of the kernel threading libraries in certain circumstances. For a network based process, it can be win. Yes, the moment you mix in disk IO, then things fall apart, but it is still a useful baseline. Also, the only way to run a 32 bit threaded binary on amd64 is to use libmap32.conf to force the app to use libc_r. Neither libthr or libpthread work for 32 bit apps running on a 64 bit kernel. I'm ok with disconnecting it from the build by default, but I think its a little premature to remove it yet. Eventually yes, but not quite yet. Now of course if libthr could be made to work for 32 bit apps on a 64 bit kernel, then that particular objection of mine goes away. (libpthread is a major drama to get working) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510251621.10384.peter>