Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jan 2000 01:02:24 -0500 (EST)
From:      Michael Bacarella <mbac@nyct.net>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, Scott Hess <scott@avantgo.com>, freebsd-hackers@FreeBSD.ORG
Subject:   rfork() [was: Concept check]
Message-ID:  <Pine.BSF.4.05.10001110055470.26127-100000@bsd1.nyct.net>
In-Reply-To: <20000110170822.J9397@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Mon, 10 Jan 2000, Alfred Perlstein wrote:

> > :I've implemented a rough fix, which is to rfork() processes which I label
[snip]
> > 
> >     The linuxthreads port is at least four times faster and, since it uses
> >     rfork(), will be I/O optimal.  However, since only FreeBSD-4.x implements
> >     rfork(...RF_MEM) you can only use it with FreeBSD-4.x (or am I wrong 
> >     there?).

This 3.4-STABLE system has an rfork() man page.

> 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?

Michael Bacarella



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?Pine.BSF.4.05.10001110055470.26127-100000>