Date: Thu, 13 Jan 2000 23:36:07 +0800 From: Peter Wemm <peter@netplex.com.au> To: "Ronald G. Minnich" <rminnich@lanl.gov> Cc: hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] Message-ID: <20000113153607.E00981CA0@overcee.netplex.com.au> In-Reply-To: Message from "Ronald G. Minnich" <rminnich@lanl.gov> of "Thu, 13 Jan 2000 07:55:25 MST." <Pine.LNX.4.20.0001121426210.6492-100000@mini.acl.lanl.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
"Ronald G. Minnich" wrote: > On Wed, 12 Jan 2000, Luoqi Chen wrote: > > > 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. > > I don't see this at all. You get many of the advantages of the single > address space: everything is shared save the stack. Most people who have > brought this up over the years want this type of behaviour, and find > themselves having to hack it in user mode, and not enjoying the > experience. I used this very version of rfork extensively for years for > shared-memory programming and it was fine. One of the things that rfork(RFMEM) does in our implementation is to share the everything from the VM data structures down to the page tables themselves. In that sharing style, it isn't possible to have processes sharing everything but the stack, at least not without context switching PTD[] slots. We used to do this on SMP for the per-cpu pages which is what prevented us from doing RFMEM style threads on SMP boxes for so long as the same pmap page directory couldn't be loaded twice on different cpus. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000113153607.E00981CA0>