Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jan 2000 06:42:26 -0800
From:      "Scott Hess" <scott@avantgo.com>
To:        "Michael Bacarella" <mbac@nyct.net>, "Alfred Perlstein" <bright@wintelcom.net>
Cc:        "Matthew Dillon" <dillon@apollo.backplane.com>, <freebsd-hackers@FreeBSD.ORG>
Subject:   Re: rfork() [was: Concept check]
Message-ID:  <1d5c01bf5c42$1409d990$1e80000a@avantgo.com>
References:  <Pine.BSF.4.05.10001110055470.26127-100000@bsd1.nyct.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Michael Bacarella <mbac@nyct.net> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1d5c01bf5c42$1409d990$1e80000a>