4 ms·

Between the `fork()` and an `exec()`, I can: * redirect stdin, stdout, and stderr * open files that might be needed and close files that aren't * c

• the_mitsuhiko 8y ago
  And ideally all these things become properties to a configuration object which is then used to spawn a process.
  • mort96 8y ago
    I'm not sure I agree it's the ideal way to do it. That's a heck of a lot of work for one function to do, and it necessarily duplicates the functionality of a ton of other functions. And that's ignoring the fact that forking without ever exec'ing can be really useful in many cases. I haven't yet read the paper, but considering the incredible simplicity from the programmer's PoV that fork provides, and the fact that at least Linux makes it pretty god damn fast, especially compared to Windows' non-forking model, I can't really see myself agreeing with their conclusion.
    • eesmith 8y ago
      When you read the paper, you'll see this covered in section 6 ("REPLACING FORK") subsection "Low-level: Cross-process operations" > While a spawn-like API is preferred for most instances of starting a program, for full generality it requires a flag, parameter, or new helper function controlling every possible aspect of process state. It is infeasible for a single OS API to give complete control over the initial state of a new process. ... > clean-slate designs [e.g., 40, 43] have demonstrated an alternative model where system calls that modify per-process state are not constrained to merely the current process, but rather can manipulate any process to which the caller has access ... > Retrofitting cross-process APIs into Unix seems at first glance challenging, but may also be productive for future research.
      • cryptonector 8y ago
        That has security considerations when spawning a process to run an executable that gets privilege on exec (think set-uid on Unix).
        • Dylan16807 8y ago
          Easy to deal with by not applying privileges until the parent is done tinkering and hits start.
          • a1369209993 8y ago
            Specifically, you'd want to do something like: pid_t child = pfork(); for(int fd=0;fd<3;fd++) p_open2(child,fd,pts,O_RDWR); char** envp = munge_env(/*parent's*/ environ); int err = p_execve(child,file,argv,envp); (Y'know, this looks kind of familiar...)
            • Dylan16807 8y ago
              I'm really not sure what you're implying, can you please state it explicitly? I'd expect this code to look similar to both the CreateProcess and fork models, at the very least.
              • eesmith 8y ago
                a1369209993's example snippet appears to be what is implied from section 6 ("REPLACING FORK"), subsection "Low-level: Cross-process operations": > clean-slate designs [e.g.,40, 43] have demonstrated an alternative model where system calls that modify per-process state are not constrained to merely the current process, but rather can manipulate any process to which the caller has access. This yields the flexibility and orthogonality of the fork/exec model, without most of its drawbacks: a new process starts as an empty address space, and an advanced user may manipulate it in a piecemeal fashion, populating its address-space and kernel context prior to execution, without needing to clone the parent nor run code in the context of the child.
    • GoblinSlayer 8y ago
      Less general functions can call more general functions, like fork calls clone on Linux.
  • JdeBP 8y ago
    You could call it posix_spawn_file_actions_t and posix_spawnattr_t . (-:
• cryptonector 8y ago
  You can do all of that with posix_spawn() as well, though some of those may require a helper program.