From owner-freebsd-hackers  Tue Sep 16 02:34:51 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id CAA14377
          for hackers-outgoing; Tue, 16 Sep 1997 02:34:51 -0700 (PDT)
Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA14363;
          Tue, 16 Sep 1997 02:34:38 -0700 (PDT)
Received: (from karpen@localhost)
	by ocean.campus.luth.se (8.8.5/8.8.5) id LAA04839;
	Tue, 16 Sep 1997 11:39:40 +0200 (CEST)
From: Mikael Karpberg <karpen@ocean.campus.luth.se>
Message-Id: <199709160939.LAA04839@ocean.campus.luth.se>
Subject: Re: What is wrong with this snipet?
In-Reply-To: <199709160858.DAA00240@dyson.iquest.net> from "John S. Dyson" at "Sep 16, 97 03:58:33 am"
To: dyson@FreeBSD.ORG
Date: Tue, 16 Sep 1997 11:39:39 +0200 (CEST)
Cc: freebsd-hackers@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

According to John S. Dyson:
> Mikael Karpberg said:
[...about rfork RFMEM...]
> > What am I missing? Could you make a short example of a use for this?
> > 
> 1)	Have a new stack ready
> 2)	Push the address of the start of the thread
> 	onto the new stack.
> 3)	call rfork with RFMEM and other flags.
> 4a)	In the child, immediately set the stack pointer to the
> 	new one that was prepared in the parent.  Issue a return
> 	instruction.
> 4b)	In the parent, continue on.
> 
> The key to this working is to avoid dependence on the stack in the
> child until the new stack pointer is loaded.
[...]

Exactly the kind of answer i was looking for. Thanx.

  /Mikael