[the_mitsuhiko]

And ideally all these things become properties to a configuration object which is then used to spawn a process.

[mort96]

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]

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]

That has security considerations when spawning a process to run an executable that gets privilege on exec (think set-uid on Unix).

[Dylan16807]

Easy to deal with by not applying privileges until the parent is done tinkering and hits start.

[cryptonector]

I don't see how. The privilege elevation mechanism cannot apply to an already-running process, since then there will be a way to subvert the process.

Now, the better answer to that is to have nothing like a set-uid mechanism, which would be nice, for sure. But just how much violence are we to do to the Unix model, and when are we expected to finish this? It's not like Linux can be abandoned -- for better or worse, Linux "won".

[eesmith]

The paper suggests:

> 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. ExOS [43] implemented fork in user-mode atop such a primitive. Retrofitting cross-process APIs into Unix seems at first glance challenging, but may also be productive for future research.

[a1369209993]

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]

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.

[cryptonector]

vfork() is the right tool. I dunno what semantics you have in mind for p_execve().

[GoblinSlayer]

Less general functions can call more general functions, like fork calls clone on Linux.

[JdeBP]

You could call it posix_spawn_file_actions_t and posix_spawnattr_t . (-: