From owner-freebsd-threads@FreeBSD.ORG Mon Apr 21 16:08:21 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 9D0C437B401 for ; Mon, 21 Apr 2003 16:08:21 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4F8443FE3 for ; Mon, 21 Apr 2003 16:08:20 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h3LN8HU93074; Mon, 21 Apr 2003 19:08:17 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Mon, 21 Apr 2003 19:08:17 -0400 (EDT) From: Jeff Roberson To: Daniel Eischen In-Reply-To: Message-ID: <20030421190707.B76635-100000@mail.chesapeake.net> 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 23:08:21 -0000 On Mon, 21 Apr 2003, Daniel Eischen wrote: > 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. thr system calls are native threads. libthr implements pthreads. I don't really care what you call it now. Go ahead and call it libpthreads. > > > > 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 > > _______________________________________________ > freebsd-threads@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > To unsubscribe, send any mail to "freebsd-threads-unsubscribe@freebsd.org" >