libpthread vs libthr.
Dag-Erling Smørgrav
des at des.no
Sat Nov 11 15:16:31 UTC 2006
Norikatsu Shigemura <nork at FreeBSD.org> writes:
> On Sat, 11 Nov 2006 01:56:29 -0500
> Kris Kennaway <kris at 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 at 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 at 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 at LIBTHREAD_1_0, Yes, libc have
> a sched_yield, but sched_yield at 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
--
Dag-Erling Smørgrav - des at des.no
More information about the freebsd-current
mailing list