Date: Tue, 25 Oct 2005 21:06:23 +0800 From: David Xu <davidxu@freebsd.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Daniel Eischen <deischen@freebsd.org>, arch@freebsd.org Subject: Re: libc_r is deprecated Message-ID: <435E2DCF.6080809@freebsd.org> In-Reply-To: <20051025120538.K52058@fledge.watson.org> References: <Pine.GSO.4.43.0510241948130.17636-100000@sea.ntplx.net> <20051025120538.K52058@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?435E2DCF.6080809>