From owner-freebsd-threads@FreeBSD.ORG Mon Apr 21 15:24:53 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85D6E37B401 for ; Mon, 21 Apr 2003 15:24:53 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEE9143FDD for ; Mon, 21 Apr 2003 15:24:52 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3LMOkBg024261; Mon, 21 Apr 2003 18:24:46 -0400 (EDT) Received: from localhost (eischen@localhost)h3LMOjuF024258; Mon, 21 Apr 2003 18:24:45 -0400 (EDT) Date: Mon, 21 Apr 2003 18:24:45 -0400 (EDT) From: Daniel Eischen To: Narvi In-Reply-To: <20030422004324.I29990-100000@haldjas.folklore.ee> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org cc: Julian Elischer Subject: Re: libkse -> libpthreads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2003 22:24:53 -0000 On Tue, 22 Apr 2003, Narvi wrote: > > On Mon, 21 Apr 2003, Daniel Eischen wrote: > > > On Mon, 21 Apr 2003, Julian Elischer wrote: > > > > > > > > WE have a small problem.. when we started we had only on pthreads > > > package and libKSE was teh heir.. > > > > No, libkse WAS libpthread. We renamed the library > > temporarily until it was proven to work reasonably > > well (I did the commit that renamed it). > > > > > now we have to live with libthr in the picture. > > > it is possible that we should think of a naming scheme that > > > allows all 3 libraries to have meaningful related names > > > > > > libc_r -> libpthreadM1 > > > libthr -> libpthreadMM > > > libkse -> libpthreadMN > > > > > > or something. > > > > The current naming scheme is fine. Libc_r is already > > a well known name along with its shortcomings. Solaris > > uses libthread for 1:1 as far as I can tell which would > > seem to match libthr, and libpthread is the POSIX threads > > library whose goal is to support POSIX as fully as > > possible (scope process and scope system). > > > > Solaris libthr is not a 1:1 thread library - the difference between Yes, I believe it now is. > libpthread and libthread is that libthread implements UI (sometimes also > called Solaris) threads, and not pthreads. And libthr threads are sorta like native threads. > > I would object to libpthread{M1,MM,MN}. We already > > had a name for libpthread. Libthr can live fine as > > libthr or libthread. > > > > No - if both provide the same API with potentially different > implementation tradeoffs, then ythe libraries should be installed with > different names and a symlink to the prefered one installed. The default library, whatever that may be, is easily changed by setting PTHREAD_LIBS, which the ports system knows about. > At least for the moment it is not clear that one of teh libraries is a > winner and will eliminate the other, It was never intended for libthr to eliminate libpthread. In fact, it was advertised as an interim solution to buy us time. Trying to work around libthr in the kernel hasn't really bought us time though. > so it would be evil to force people > to explicitly link against one or the other causing future compatibility > problems. Both provide the same pthreads API so there is no reasonable > case for demanding that one of them can't have its SONAME be > libpthpread.so.1 We can, in libpthread, build it so that every thread is 1:1. True, we might not be able to do this without a small amount of overhead right now, but it will be possible in the future. If built that way, we can install it as libthr so that any application relying on libthr.so.1 will still have it there. This has been one of my goals for some time. I want libpthread to get out there for 5.1. I want to see those bug reports roll in, so that by the time 5.2 (-stable) comes around we have a good handle on what the problems are and have addressed them. We have 3 people (David Xu, Julian, and myself) wanting to maintain this and keep it moving forward. I don't want to see it go away. -- Dan Eischen