From owner-freebsd-hackers Tue Jan 11 6:43:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 81F8F15000 for ; Tue, 11 Jan 2000 06:43:16 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 227; Tue, 11 Jan 2000 06:38:48 -0800 Message-ID: <1d5c01bf5c42$1409d990$1e80000a@avantgo.com> From: "Scott Hess" To: "Michael Bacarella" , "Alfred Perlstein" Cc: "Matthew Dillon" , References: Subject: Re: rfork() [was: Concept check] Date: Tue, 11 Jan 2000 06:42:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Bacarella wrote: > On Mon, 10 Jan 2000, Alfred Perlstein wrote: > > I'm pretty sure RF_MEM doesn't work in 3.x with SMP, under UP it should > > work fine > > I'm sorry I missed the discussion on rfork()... but I say this only > because I want to understand. > > What were you thinking? rfork()? Why is it a system call? > > Almost all of the flags it accepts seem like functionality that can easily > be implemented in userspace around fork() (and maybe vfork()). > > Why? You've got that backwards - fork() and vfork() can easily be implemented in terms of rfork() [in fact, I believe all three are implemented in terms of 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. rfork() without RFFDG shares file descriptor tables - current AND FUTURE. fork() is like rfork(RFFDG) in that the current file descriptors are copied, but going forward they are seperate tables. The pthreads mods I'm proposing use this to allow the iothreads to have access to the same set of file descriptors as the primary process, even if the primary process opened the file descriptor after the iothread was spawned. In fact, the iothread can be used to open() or close() the file descriptor. Later, scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message