Date: Sat, 11 Nov 2006 23:53:32 +0900 From: Norikatsu Shigemura <nork@FreeBSD.org> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-current@FreeBSD.org Subject: Re: libpthread vs libthr. Message-ID: <20061111235332.89f24170.nork@FreeBSD.org> In-Reply-To: <20061111065629.GA82094@xor.obsecurity.org> References: <20061110151247.GA64530@zone3000.net> <20061111022044.8191e1c8.nork@FreeBSD.org> <20061111065629.GA82094@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 11 Nov 2006 01:56:29 -0500
Kris Kennaway <kris@obsecurity.org> wrote:
> On Sat, Nov 11, 2006 at 02:20:44AM +0900, Norikatsu Shigemura wrote:
> > On Fri, 10 Nov 2006 17:12:47 +0200
> > Nikolay Pavlov <quetzal@zone3000.net> wrote:
> > > Hi. In this post i am not trying to raise a discussion about teoretical
> > > advantages of some special threading model, but still i would like to
> > > figure out why libthr in it current state is not our default posix
> > > thread library and could it be so in time of 7-STABLE?
> > I don't agree. Do test, run by again, do test.
> > I read a discussion about libpthread vs libthr, so I tested on
> > my environments(7-current SMP and 6-stable UP). My result is
> > NOT YET, and I resurrected to libpthread environment.
> > 1. libthr is not enough mature.
> > At this time, libpthread's pthread API support > libthr's
> > pthread API support. So libthr lacks of compatibility with
> > libpthread. It is not good.
> Which applications does this effect? I'm not aware of any (see
> below).
> > 2. Not PTHREAD_CFLAGS/PTHREAD_LIBS clean
> > At this time, tinderbox doesn't test PTHREAD_CFLAGS/
> > PTHREAD_LIBS clean. We have need to check PTHREAD_CFLAGS/
> > PTHREAD_LIBS clean on all ports.
> The existence of libmap makes this objection irrelevant. Also,
> sparc64 uses libthr by default and I'm not aware of any resulting port
> build problems. So apparently any missing API features are not widely
> used, or are successfully worked around. Can you provide evidence to
> the contrary?
My case is gdm (x11/gdm). gdm doesn't works by using libthr
instead of libpthread (changing by libmap). gdm couldn't
resolve a symbol, sched_yield(2). So X server didn't run.
In this case, gdm tried to resolve a symbol,
sched_yield@LIBTHREAD_1_0 instead of sched_yield. So by changing
libthr by libmap, gdm couldn't resolve a symbol, sched_yield(2).
libthr doesn't have a sched_yield@LIBTHREAD_1_0, Yes, libc have
a sched_yield, but sched_yield@LIBTHREAD_1_0.
This problem can resolve by recompiling all applications by using
libthr like PTHREAD_LIBS=-lthr, I believe. And I don't have
confidence about all applications conforming PTHREAD_LIB=-lthr.
In sparc64 case, -pthread is libthr(by symlink), but in i386 and
some other arch case, -pthread is libpthread. So compiling
condition is too different.
> > 3. Is libthr environments useful?
> > I don't think. Yes, I think that some applications like mysql
> > are useful. However, in all FreeBSD environment system, by 1
> > and 2, libthr is not useful.
> Maybe you don't care that libpthread's performance is terrible and
> e.g. this makes FreeBSD look bad on benchmarks, both published and
> when a user evaluates FreeBSD against other systems to decide whether
> or not to use it on their workloads - but surely most people do.
I agree about a performance problem and libthr bringing
performance UP. But we cannot mix libpthread and libthr in a
application (= a process). One application use libthr, but one
plugin called by it use libpthread. it doesn't work:-(. By
using libthr, libthr brings performance UP but application is
crashed, it is not good.
Therefore, I like ru's suggestion (${MK_LIBPTHREAD}=="no" check).
But it is not evidence of PTHREAD_CFLAGS/PTHREAD_LIBS clean.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061111235332.89f24170.nork>