Re: libpthread vs libthr.

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