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