From owner-freebsd-hackers Wed Jan 12 12:25:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 9684014DAA for ; Wed, 12 Jan 2000 12:25:51 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id PAA14283; Wed, 12 Jan 2000 15:25:49 -0500 (EST) (envelope-from luoqi) Date: Wed, 12 Jan 2000 15:25:49 -0500 (EST) From: Luoqi Chen Message-Id: <200001122025.PAA14283@lor.watermarkgroup.com> To: hackers@FreeBSD.ORG, rminnich@lanl.gov Subject: Re: rfork() [was: Concept check] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Matthew Dillon wrote: > > > :BTW, concerning rfork(RFMEM). Could somebody explain me, why the > > > :following simple program is coredumping: > > > You cannot call rfork() with RFMEM directly from a C program. You > > > have to use assembly (has anyone created a native clone() call yet > > > to do all the hard work?). > > OK, I'd like to propose another option to rfork to make it a little more > usable for mortals. The option is RFSTACK. This will cause rfork to work > like my original version, in that the stack segment (all memory from > USERSTACK and up) will be cloned. > > This would really make a big improvement in rfork usability. > > Comments? > > ron > It's almost a regular fork(), we lose all the advantages of a single address space. A rfork(RFMEM) wrapper can achieve the same level of usability without sacrificing the performance, and IMO is a preferred solution. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message