From owner-freebsd-arch@FreeBSD.ORG Tue Oct 25 23:21:11 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B34716A41F for ; Tue, 25 Oct 2005 23:21:11 +0000 (GMT) (envelope-from peter@wemm.org) Received: from daintree.corp.yahoo.com (daintree.corp.yahoo.com [216.145.52.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1846643D45 for ; Tue, 25 Oct 2005 23:21:11 +0000 (GMT) (envelope-from peter@wemm.org) Received: by daintree.corp.yahoo.com (Postfix, from userid 2154) id E73671976C; Tue, 25 Oct 2005 16:21:10 -0700 (PDT) From: Peter Wemm To: freebsd-arch@freebsd.org Date: Tue, 25 Oct 2005 16:21:10 -0700 User-Agent: KMail/1.8.2 References: <20051025120538.K52058@fledge.watson.org> <435E2DCF.6080809@freebsd.org> In-Reply-To: <435E2DCF.6080809@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510251621.10384.peter@wemm.org> Subject: Re: libc_r is deprecated X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 23:21:11 -0000 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