13 May
2024
13 May
'24
9:29 a.m.
On Sun, May 12, 2024 at 4:57 PM Dan Cross <crossd(a)gmail.com> wrote:
l.
Perhaps, but as I've written here before, `fork`/`exec` vs `spawn` is
a false dichotomy. Another alternative is a `proccreate`/`procrun`
pair, the former of which creates an unrunnable process, the latter of
which marks it runnable. Coupled with a set of primitives to
manipulate the state of an extant, but unrunnable, process and you
have the advantages of fork/exec without the downsides (which are
well-known;
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.…)
Similarly, this gives you the functionality of spawn, without the
downside of a singularly complicated interface. Could you have
implemented that in something as small as the PDP-7? Perhaps not, but
it does not follow that `fork` now remains a good primitive.
IMO something like that is the best model (although it probably would
have been a bit complicated for a PDP-7/PDP-11). That's basically what
I'm doing in the OS that I'm writing
<https://gitlab.com/uxrt/uxrt-toplevel>. Processes will basically just
be containers for hierarchical groups of threads, and will have pretty
much no other state besides the command line. All of the context
normally associated with a process (file descriptor space,
permissions/UID/GID, filesystem namespace, virtual address space) will
instead be in separate objects that are explicitly bound to threads.
Separate APIs for creating an empty process, creating threads within
it, manipulating context objects and binding threads to them, and
starting the process will be provided (all of these APIs will use a
file-based transport underneath; this will be the first OS I know of
where literally everything is a file). The base process APIs will be
general enough to allow an efficient copy-on-write fork() to be
implemented on top of them for backwards compatibility and the
remaining use cases where forking still makes sense (since even all
process memory will be implemented with files, this will be
implemented with a special in-memory "shadow filesystem" that creates
alternate mappings of other memory filesystems).
Really I'd say there are actually several design decisions in
conventional Unix that made sense on a PDP-7 or PDP-11, but no longer
make sense in the modern world. For instance, the rather inflexible
security model with its fixed set of root-only system calls rather
than some form of role-based access control, or the use of on-disk
device nodes bound by numbers rather than something like separate
special filesystems for each driver that get union mounted together,
or the lack of integrated support for userspace filesystem servers
(yes, there's FUSE, but it's kind of a poorly integrated hack that is
rarely used for anything important).