3 ms·
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
by 10000truths 5y 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().
- univspl 5y agoTo 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)
- wongarsu 5y agoWindows 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.
- notriddle 5y agoThat'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.
- ChrisSD 5y agoA 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.
- monocasa 5y agoPractically, 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.
- LeifCarrotson 5y agoBut 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!
- deleted 5y ago[deleted]