libc_r is deprecated

Peter Wemm peter at wemm.org
Tue Oct 25 16:21:11 PDT 2005


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 at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5


More information about the freebsd-arch mailing list