From owner-freebsd-hackers Tue Jan 11 22:41:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id F01B414FAD for ; Tue, 11 Jan 2000 22:41:38 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 5219 invoked by uid 1001); 12 Jan 2000 06:41:29 -0000 Date: Tue, 11 Jan 2000 22:41:29 -0800 From: Jason Evans To: Matthew Dillon Cc: Alexander Litvin , Scott Hess , hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] Message-ID: <20000111224129.K302@sturm.canonware.com> References: <200001120534.AAA10170@unknown.nowhere.org> <200001120556.VAA67332@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001120556.VAA67332@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Jan 11, 2000 at 09:56:58PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jan 11, 2000 at 09:56:58PM -0800, Matthew Dillon wrote: > > :> fork1() in the kernel]. rfork(RFMEM) means that the processes share all > :> memory - current AND FUTURE. You could use minherit() before fork() to > :> share current memory, but not future memory. > : > :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?). > > The reason is that rfork(RFMEM) does not give the new process a new > stack, so both the old and new processes wind up on the same original > stack and stomp all over each other. There is an implementation of clone() in the linuxthreads port, written by Richard Seaman. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message