From owner-freebsd-current@FreeBSD.ORG Sat Nov 11 14:53:43 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99D2916A403 for ; Sat, 11 Nov 2006 14:53:43 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D41F43D49 for ; Sat, 11 Nov 2006 14:53:42 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from mail.ninth-nine.com ([IPv6:2001:3e0:4cf:1:d2:ff:fe23:1b4]) (authenticated bits=0) by sakura.ninth-nine.com (8.13.8/8.13.8/NinthNine) with ESMTP id kABEramT080639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Nov 2006 23:53:41 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 11 Nov 2006 23:53:32 +0900 From: Norikatsu Shigemura To: Kris Kennaway 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> X-Mailer: Sylpheed version 2.3.0beta4 (GTK+ 2.10.6; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (sakura.ninth-nine.com [IPv6:2001:3e0:4cf:0:230:48ff:fe41:2455]); Sat, 11 Nov 2006 23:53:41 +0900 (JST) Cc: freebsd-current@FreeBSD.org Subject: Re: libpthread vs libthr. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 14:53:43 -0000 On Sat, 11 Nov 2006 01:56:29 -0500 Kris Kennaway 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 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.