From owner-freebsd-hackers  Mon Jun 28  9:28:30 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
	by hub.freebsd.org (Postfix) with ESMTP id 4886614C01
	for <hackers@FreeBSD.ORG>; Mon, 28 Jun 1999 09:28:23 -0700 (PDT)
	(envelope-from julian@whistle.com)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22])
	by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id JAA20683;
	Mon, 28 Jun 1999 09:28:12 -0700 (PDT)
Date: Mon, 28 Jun 1999 09:28:11 -0700 (PDT)
From: Julian Elischer <julian@whistle.com>
To: Warner Losh <imp@harmony.village.org>
Cc: "Daniel J. O'Connor" <doconnor@gsoft.com.au>, hackers@FreeBSD.ORG
Subject: Re: "restricted" kernel threads implementation from NetBSD via n 
In-Reply-To: <199906281426.IAA15234@harmony.village.org>
Message-ID: <Pine.BSF.3.95.990628092421.10211C-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG



On Mon, 28 Jun 1999, Warner Losh wrote:

> In message <XFMail.990628173909.darius@dons.net.au> "Daniel J. O'Connor" writes:
> : I don't suppose someone could post an explanation of how kernel threads work
> : could they? :)
> 
> Looks like it just does a fork like thing so it can do context
> switches...

To be more precise, it should be more like a rfork() like thing
that doesn't change any resources except the stack, a process structure
and processor context. Specifically, processor VMspace is basically left
at whatever it is already at, and there is no 'signal' stuff or file
descriptor table munging. We might even allow the MMU to be left unchanged
too.

julian




> > Warner
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message