Re: libpthread vs libthr.

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 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.