On Mon, 5 Jun 2000, Jason R Thorpe wrote:

> I have a hard time calling something rfork(2) if it doens't work like the
> original rfork(2) (as seen in Plan 9).  IMO, the FreeBSD people choose a
> poor name for thier __clone()-like system call.

  I'm looking for the Plan 9 version (different address spaces that share
a number of segments).  I didn't notice the FreeBSD one was different when
I glanced at the man pages (they seem to have forgotten to delete the part
of the Plan 9 man page about shared segments, though they did mention that
the entire address space shared so it should have been obvious that the
rest of that paragraph was just cruft).  I agree that this was a very poor
choice by FreeBSD.

  After more thought, I think BSDi is on the right track by separating the
creation of a new thread and the forking of resources (though I don't know
the details of what BSDi has done... the only discussion of it I could
find was a message by Chris Torek on some perl mailing list (archived at
http://www.mit.edu:8008/bloom-picayune.mit.edu/perl/12389)).  Anyone from
BSDi out there who could explain sfork in more detail?

You would have, say:

1) tfork() -- fork a new thread with *all* resources (including address
space) shared.  The parent will block and sfork will return 0 in the new
process.  The parent will be unblocked when the child exits or execs.
This is almost exactly vfork except that file descriptors and such are
still shared.  The child process should then either set up shop on a new
stack or fork its address space.  This might or might not be BSDi sfork.

2) ufork(int flags) -- fork the indicated resources for this thread.  BSDi
presumably has something like this to go with sfork, but I don't know what
it is.  It would be nice to be compatible if possible.

Flags are:
	FORK_UNBLOCK	-- unblock the parent process
	FORK_VM		-- address space (data, bss, and any shared
			segments are still shared).
	FORK_SHARED	-- shared segments, data, and bss (implies
			FORK_VM)
	FORK_FS		-- fs root, cwd, umask
	FORK_FILES	-- file descriptors
	FORK_SIGHAND	-- signal handlers

  You can use these to implement fork, vfork, both rforks, and something
like clone except for the exit signal.

> I see little value in MAP_STACK.  The reference model for threads (Solaris)
> doesn't need it.  I don't see why we should.  If you want it to avoid pre-
> allocating swap space for stack pages, then again we can follow Solaris's
> lead and implement MAP_NORESERVE.

  You are right, that would be much better.

  Hmm... what syscall(s) does Solaris use for threading?

Matthew Orgass
darkstar@pgh.net