[TUHS] Re: forking, Re: [COFF] Re: On Bloat and the Idea of Small Specialized Tools

[Dan Cross <crossd@gmail.com>]

On Sun, May 12, 2024 at 4:14 PM John Levine <johnl@taugh.com> wrote:
> It appears that Larry McVoy <lm@mcvoy.com> said:
> >Perhaps a meaningless aside, but I agree on fork().  In the last major
> >project I did, which was cross platform {windows,macos, all the major
> >Unices, Linux}, we adopted spawn() rather than fork/exec.  There is no way
> >(that I know of) to fake fork() on Windows but it's easy to fake spawn().
>
> The whole point of fork() is that it lets you get the effect of spawn with
> a lot less internal mechanism.  Spawn is equivalent to:
>
>   fork()
>   ... do stuff to files and environment ...
>   exec()
>
> By separating the fork and the exec, they didn't have to put all of
> the stuff in the 12 paragraphs in the spawn() man page into the the
> tiny PDP-11 kernel.

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.pdf).
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.

My spelunking in the original GENIE documentation leads me to believe
that its `fork` provided functionality similar to what I described.

        - Dan C.