Comment by 10000truths
4 years ago
Because there are many, many use cases where you don't want to call exec() immediately after fork().
Want to constrain memory usage or CPU time of an arbitrary child process? You have to call setrlimit() before exec(). Privilege separation? Call setuid() before exec(). Sandbox an untrusted child process in some way? Call seccomp() (or your OS equivalent) before exec(). And so on and so forth. Any time you want to change what OS resources the child process will have access to, you'll need to do some set-up work before invoking exec().
Windows solves this by adding a bunch of optional parameters to CreateProcess, as well as having two more variants (CreateProcessAsUser and CreateProcessWithLogon). Some of the arguments are complicated enough that they have helper functions to construct them.
I like the more composable fork()->modify->exec() approach of unix, but I wouldn't call either of them really elegant.
That's one option, yes.
The one I've favored while reading these arguments has been the "suspended process" model. The primitives are CREATE(), which takes an executable as a parameter and returns the PID of a paused process, and START(), which allows the process to actually run.
Unix already has the concept of a paused executable, after all.
This model also requires all the process-mutation syscalls, like setrlimit(), to accept a PID as a parameter, but prlimit() wound up being created anyway, because the ability to mutate an already-running process is useful.
A third way is to grant the parent process access to the child such that they can use the child process handle to "remotely" set restrictions, write memory, start a thread, etc.
Practically, syscall overhead has gotten in the way of that being the ubiquitous in the past. Here's to hoping that newer models of syscalls that reduce kernel/user overhead make such a thing possible.
To me this feels like a call for more powerful language primitives. i.e. a way to specify some action to take to "set up" the child process that's more explicit and readable than one special behaving in a particularly odd way. I'm imagining closures with some kind of Rust-like move semantics, but not entirely sure.
(if we're speaking in terms of greenfield implementation of OS features)
Yeah, this. Why not mkprocess/exec instead of fork/exec?
Builder patterns for primitives? I think that seems super cool but then aren't you just building a new language?
But my child processes are not arbitrary or untrusted, they're hard-coded and written by me!
I'm not writing a shell, I'm writing an application!