[kps]

Fork is conceptually simple. Without bringing in any other layers, you start a process with the one thing known to exist: yourself.

Otherwise you need multiple steps to create a process, fill it with something to run, and arrange for it to execute. Or like Win32 you permanently smush them together with other layers, like filesystems and object loaders and linkers.

[IshKebab]

It's not conceptually simple. No other object creation API works by copying an existing thing and then modifying it. You don't create a new file by copying an existing one and then modifying it. You don't create a new window by copying an existing one and modifying it.

Attempting to justify clone/exec as a reasonable design is just Stockholm syndrome.

[kps]

> No other object creation API works by copying an existing thing and then modifying it.

Clone-and-modify is pretty common in CAD.

> You don't create a new file by copying an existing one and then modifying it.

Clone-and-modify is almost universal in version control systems.

[IshKebab]

> Clone-and-modify is almost universal in version control systems.

It's closer to copy-on-write. Also, it actually makes sense there because in 99.999% of cases a commit actually is a modified copy of its parent. That isn't true for process spawning.

[Too]

Fill with what stuff exactly?

The only thing I want to inherit from the parent process is its cwd and environment variables, even those are often overridden. The rest can easily be passed explicitly through other channels like pipes or command line arguments.

Back to the example from the article. It makes no sense that a git-subprocess forked from a web server need to have any process state inherited from the web server.

[kps]

> Fill with what stuff exactly?

Yes, exactly. Cloning, as a process creation primitive, is the one thing that doesn't need to be concerned with other stuff.

> … a git-subprocess forked from a web server …

That's pulling in a whole load of assumptions that are distinct from process creation. You can have processes in an environment that has no concept of file system or persistent storage at all.

[ajkjk]

I gues that way of thinking makes sense if you have a certain model of what a process is, in terms of the data structures and runtime state etc. But, tbh, I think of processes as glorified function calls, which happen to have that stuff involved as an implementation detail. And if spawning a process call is supposed to act like a function call, then of course it should not inherit state. You should call the function you want to call, not call yourself with an instruction to switch over to it instead.

[fluffybucktsnek]

Conceptually, processes are more akin to units of isolation. Threads are closer to function calls.