From owner-freebsd-threads@FreeBSD.ORG Mon Apr 21 11:38:16 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 77DFD37B401 for ; Mon, 21 Apr 2003 11:38:16 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3F3E43FBF for ; Mon, 21 Apr 2003 11:38:15 -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 h3LIcBBg019003; Mon, 21 Apr 2003 14:38:12 -0400 (EDT) Received: from localhost (eischen@localhost)h3LIcBPq018989; Mon, 21 Apr 2003 14:38:11 -0400 (EDT) Date: Mon, 21 Apr 2003 14:38:11 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3EA4382F.6CA7C63A@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: libkse -> libpthread 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 18:38:16 -0000 On Mon, 21 Apr 2003, Terry Lambert wrote: > Jeff Roberson wrote: > > On Mon, 21 Apr 2003, Daniel Eischen wrote: > > > Since libkse seems to be generally useful, anyone mind if I > > > go back to installing it as libpthread? > > > > There is some question over whether kse or thr will be the default > > threading implementation for 5.1. I think this should be discussed before > > we decide on what lib uses libpthread. > > Isn't libthr really just libkse with N = M? Yes, I wasn't going to bring that up, though. > These should behave exactly the same, right? It should even be > possible to drop the UTS out of the picture for everything but > signal handling, I think (i.e. it would never get upcalled) in > the 1:1 case, if this were done? Libpthread can be made to behave the same as libthr just by forcing every thread to be scope system. Currently, the implementation for scope system threads does have a small amount of overhead in that they still get upcalls after the thread blocks in the kernel (in this case the KSE just reenters the kernel with kse_release() and waits for the thread to become unblocked). These KSEs also require a small stack separate from the thread's stack. The code is in place (in the UTS) to not require a separate stack and not get any upcalls for these threads, but we just need a bit more kernel work to optimize this overhead away. I do have scope system threads running in a simple test program. -- Dan Eischen