From owner-freebsd-threads@FreeBSD.ORG Mon Apr 21 17:49:26 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 43DEF37B401 for ; Mon, 21 Apr 2003 17:49:26 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6983F43FAF for ; Mon, 21 Apr 2003 17:49:25 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0346.cvx21-bradley.dialup.earthlink.net ([209.179.193.91] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 197lyA-0000Kb-00; Mon, 21 Apr 2003 17:49:11 -0700 Message-ID: <3EA49134.71A5BDC8@mindspring.com> Date: Mon, 21 Apr 2003 17:47:48 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Narvi References: <20030422020939.S29990-100000@haldjas.folklore.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4cb31d744f6166ad1e0da695f36c568db350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: "Geoffrey C. Speicher" cc: threads@freebsd.org 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:49:26 -0000 Narvi wrote: > On Mon, 21 Apr 2003, Geoffrey C. Speicher wrote: > > What's not clear about it? libkse is a superset of the functionality > > of libthr. Seems pretty straightforward to me that the long-term > > winner is libkse. > > This assumes that libkse M:N model will provide supperior performance and > scalability, and this is not clear. Or does merely the fact that itis M:N > somehow make it more winning contender? See other discussion. Performance should be identical, after the upcall is eliminated in the case where all threads are created PTHREAD_SCOPE_SYSTEM, and libkse communicates this to the kernel to avoid generation of upcalls on blocking operations. Jeff makes a good point about the potential for bugs because of the more sophisticated and larger total number of lines of code, however. Daniel also makes a good point about not finding them unless the code is put in production. To my mind, it comes down to bug avoidance vs. bug detection, if you weigh these arguments against each other. -- Terry