Subject: Re: Why no /usr/include/sys/kthread.h?
To: Jason R Thorpe <email@example.com>
From: Matthew Orgass <firstname.lastname@example.org>
Date: 06/06/2000 15:01:11
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.
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_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?