[TUHS] fork (Re: Systematic approach to command-line interfaces

[Bakul Shah <bakul@iitbombay.org>]

On Aug 2, 2021, at 2:25 PM, Dan Cross <crossd@gmail.com> wrote:
> 
> Fork has served us well for more than five decades; I've got no argument with that. However, should we never question whether it continues to be the right, or best, abstraction as the environment around it continues to evolve?

An os with no fork() can be used to reimplement fork() for backward 
compatibility. You will anyway need all the things fork() used to do
in this brave new world. For example, you will need to specify which
signals and file descriptors to inherit. Something like:

jmp_buf state;
pid = 0;
if (!setjmp(state) && !pid) {
	fd = openAt(hostfd, "/n/address-space/new", ...);
	<<copy /proc/self/mem to fd.>>
	pid = breathe_life(fd, state, signals, fds);
	longjmp(state, 1);
	return pid;
}

The /n/address-space filesystem yields a new address space on a
given host (as represented by the hostfd). You can then "copy"
to it to fill it up from the current proc's memory. Copy should
be done using COW if the new proc is on the same host (or even
remote but that opens up another area of discussion...).

breathe_life is given where everything is set up and it just has to
create a new thread, associated with the address, wire up signals
as file descriptors that are to be inherited and arrange things
so that on return from syscall in the child, process state will be
as per "state".

If signals and fds can be wired up to a remote host, this can be
used to "migrate" a process. There is likely much more process
state in the kernel mode which would have to be packaged up somehow.

There may be other breakage if the child & parent are on different
hosts.