From owner-freebsd-arch@FreeBSD.ORG Tue Oct 25 11:06:48 2005 Return-Path: X-Original-To: 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 8C25116A41F; Tue, 25 Oct 2005 11:06:48 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A42D43D53; Tue, 25 Oct 2005 11:06:47 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 410F346BB0; Tue, 25 Oct 2005 07:06:47 -0400 (EDT) Date: Tue, 25 Oct 2005 12:06:47 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Daniel Eischen In-Reply-To: Message-ID: <20051025120538.K52058@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, David Xu 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 11:06:48 -0000 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