Date: Sat, 11 Nov 2006 16:16:25 +0100 From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Norikatsu Shigemura <nork@FreeBSD.org> Cc: freebsd-current@FreeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: libpthread vs libthr. Message-ID: <86lkmivws6.fsf@dwp.des.no> In-Reply-To: <20061111235332.89f24170.nork@FreeBSD.org> (Norikatsu Shigemura's message of "Sat, 11 Nov 2006 23:53:32 %2B0900") References: <20061110151247.GA64530@zone3000.net> <20061111022044.8191e1c8.nork@FreeBSD.org> <20061111065629.GA82094@xor.obsecurity.org> <20061111235332.89f24170.nork@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Norikatsu Shigemura <nork@FreeBSD.org> writes: > 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 teoreti= cal >> > > 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=20 >> > > 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 is not a libthr issue, it's a symbol versioning issue. Arguably, sched_yield should be removed from libpthread's symbol map, because it's a wrapper for a syscall and we don't version syscalls. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86lkmivws6.fsf>