The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Bakul Shah <>
To: Dan Cross <>
Cc: The Eunuchs Hysterical Society <>
Subject: [TUHS] fork (Re:  Systematic approach to command-line interfaces
Date: Mon, 2 Aug 2021 17:20:41 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Aug 2, 2021, at 2:25 PM, Dan Cross <> 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

  parent reply	other threads:[~2021-08-03  0:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02  2:42 [TUHS] " Douglas McIlroy
2021-08-02 14:58 ` Theodore Ts'o
2021-08-02 18:15   ` Adam Thornton
2021-08-02 18:24     ` Warner Losh
2021-08-02 20:55     ` John Cowan
2021-08-02 21:06       ` Jon Steinhart
2021-08-02 21:25         ` Dan Cross
2021-08-02 21:59           ` Jon Steinhart
2021-08-02 22:33             ` John Cowan
2021-08-03  0:20           ` Bakul Shah [this message]
2021-08-03  0:59             ` [TUHS] fork (Re: " Adam Thornton
2021-08-03  1:20               ` Steve Nickolas
2021-08-03  0:21     ` [TUHS] " Bakul Shah
2021-08-03  1:49       ` Jon Steinhart
2021-08-03  3:21         ` Adam Thornton
2021-08-03  3:27         ` Bakul Shah
2021-08-03  3:51           ` Jon Steinhart
2021-08-03  7:19   ` arnold
2021-08-03 23:12     ` Andrew Warkentin
2021-08-04 15:04       ` Paul Winalski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).