From owner-freebsd-threads@FreeBSD.ORG Mon Apr 21 17:25:35 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 8428737B401 for ; Mon, 21 Apr 2003 17:25:35 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD7AE43FA3 for ; Mon, 21 Apr 2003 17:25:34 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0346.cvx21-bradley.dialup.earthlink.net ([209.179.193.91] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197lbD-0000ld-00; Mon, 21 Apr 2003 17:25:28 -0700 Message-ID: <3EA48BA6.E152E654@mindspring.com> Date: Mon, 21 Apr 2003 17:24:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Narvi References: <20030422004324.I29990-100000@haldjas.folklore.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a400de5aba062d2b40ac5e1ad87aacbf8d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: threads@freebsd.org cc: Daniel Eischen 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: Tue, 22 Apr 2003 00:25:35 -0000 Narvi wrote: > Solaris libthr is not a 1:1 thread library - the difference between > libpthread and libthread is that libthread implements UI (sometimes also > called Solaris) threads, and not pthreads. And back in SunOS 4.1.3_U2 days, and carried forward for binary compatability for a while, there was a "liblwp", which was a user space call conversion threads library, very much like our modern FreeBSD libc_r. Everything old is new again... 8-). > > 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. > > At least for the moment it is not clear that one of teh libraries is a > winner and will eliminate the other, 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 FWIW: My post earlier, and Daniel's response, were meant to highlight the fact that there are, in fact, only different tradeoffs at this point because the libkse gets an upcall on block and calls kse_release() in the 1:1 case, but otherwise has identical function as libthr (no other tradeoffs). The upcalls and the kse_release(), as well as UTS entry, could be (and are intended to be) eliminated in the PTHREAD_SCOPE_SYSTEM case. After that, there are *NO* implementation tradeoffs between the two; libkse is a complete superset of libthr. The only real difference, after that, is that the signals in libthr are questionable (i.e. they have been questioned but not answered to everyone's satisfaction), and that it's impossible for libthr to implement the proper POSIX compliant semantics for PTHREAD_SCOPE_PROCESS. It's really important for people to understand both implementations well enough to be able to comment on them, before claiming differences that are really not there. -- Terry