Re: libc_r is deprecated

From: Peter Wemm (peter_at_wemm.org)
Date: 10/26/05

  • Next message: Daniel Eischen: "Re: libc_r is deprecated" 
    To: freebsd-arch@freebsd.org
Date: Tue, 25 Oct 2005 16:21:10 -0700

    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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
  • Next message: Daniel Eischen: "Re: libc_r is deprecated"