From owner-freebsd-threads@FreeBSD.ORG  Thu Apr  3 12:55:13 2003
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
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 1E01037B404
	for <freebsd-threads@FreeBSD.ORG>;
	Thu,  3 Apr 2003 12:55:13 -0800 (PST)
Received: from canning.wemm.org (canning.wemm.org [192.203.228.65])
	by mx1.FreeBSD.org (Postfix) with ESMTP id AFABC43FB1
	for <freebsd-threads@FreeBSD.ORG>;
	Thu,  3 Apr 2003 12:55:12 -0800 (PST)	(envelope-from peter@wemm.org)
Received: from wemm.org (localhost [127.0.0.1])
	by canning.wemm.org (Postfix) with ESMTP
	id 99A882A8A5; Thu,  3 Apr 2003 12:55:12 -0800 (PST)
	(envelope-from peter@wemm.org)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: "Geoffrey C. Speicher" <geoff@speicher.org>
In-Reply-To: <Pine.BSF.4.05.10304031503370.2892-100000@speicher.org> 
Date: Thu, 03 Apr 2003 12:55:12 -0800
From: Peter Wemm <peter@wemm.org>
Message-Id: <20030403205512.99A882A8A5@canning.wemm.org>
cc: freebsd-threads@FreeBSD.ORG
Subject: Re: 1:N threading 
X-BeenThere: freebsd-threads@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Threading on FreeBSD <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Apr 2003 20:55:13 -0000

"Geoffrey C. Speicher" wrote:
> OK, so we've got 1:N threading (libc_r), 1:1 threading (thr), and M:N
> threading (KSE).  Each model has its own merit depending on the
> application.
> 
> However, it would still be nice if the 1:N model didn't block the whole
> process when a thread blocks.  Is there any reason to hold onto a pure
> userland implementation of 1:N?  Can libc_r be implemented in terms of
> KSE?

It probably could be extended to recover context when it blocks, but by the
time you go that far you may as well just remove the select() wrappers and
use the context recovery in the default case.  And then you're most of the
way to libkse anyway, the main remaining difference would be to allow more
than one execution point at a time.

FWIW, libkse has got large chunks of libc_r in it.  So has libthr.

Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5