🚀 go-pugleaf

I guess that most people are used to using fork() and not having a
shared address space between processes.  We could eliminate fork() and
exec() in favor of create() and activate(), where:

create(program, procedure, argv, argc)  ----  creates a new process to
execute your favorite procedure out of your favorite program.  The stack
of the child process is initially empty; i.e., if the procedure returns,
then the child terminates.  Here's the twist --- the process is
initially suspended.

activate(child) ---- yep, it awakens the initially suspended child! :-)

Here's the key point: between the create() and the activate(), the
parent process can do all of those wonderful things that others have
moaned and groaned need to be done between a fork() and an exec().  We
need only have separate kernel calls that allow a parent process to
manipulate the environment of its suspended children.  So you could set
up your child's stdin, stdout, etc.  In fact, this method is even MORE
general, because the parent process could (if your OS was willing)
modify the child's global variables before letting it run; whereas with
exec(), the child's global variables are reinitialized from the new core
image.  (This raises issues of protection that I don't really care
about; so let's not flame over that issue, ok?)

And of course this method, which requires true sharing of data between
processes, does NOT need to copy the parent's stack or global data.  If
you really need the child to have the same global data as you have, then
you could write your own block copy loop; if you don't need such
copying, then create() and activate() won't do it --- whereas fork()
always will, whether by COW or otherwise.  So this new methodology is
more efficient that fork()/exec().

So, as I said before, we do NOT need COW to efficiently support the
spawning of new processes.  We need only avoid a brain dead fork().

Richard Huff
huff@svax.cs.cornell.edu