Just as a confirmation that using Spawn might not be such a bad idea (and adding it to Eio_unix), I added a backend to kqueue using it + an Eio.Process module here: patricoferris@9875511

Regarding PATH, I'd leave that out of the low-level API (which should just export what the OS provides).

W.r.t this comment:

Regarding PATH, I'd leave that out of the low-level API (which should just export what the OS provides).

We now vendor spawn so have a little more control over what we can do on the C-side of things, did you mean to just mark it as calling execve and let the user worry about things like PATH ?

We now vendor spawn so have a little more control over what we can do on the C-side of things, did you mean to just mark it as calling execve and let the user worry about things like PATH ?

Yes.

The spawn library has a single function that does a lot of stuff, and different platforms will want to provide different features. I'm wondering if it would be better to make it more modular.

The basic problem we have is that we can't call OCaml code after forking. However, we can make a list of C functions to call. Here's an experiment that defines a Fork_action.t and has spawn take a list of those:

https://github.com/ocaml-multicore/eio/compare/main...talex5:eio:spawn?expand=1

e.g. (I put this in eio_posix, but it's demonstrating the Linux-specific execveat and fchdir actions here):

open Eio.Std

module L = Eio_posix.Low_level

let () =
  Eio_posix.run @@ fun _env ->
  Switch.run @@ fun sw ->
  let exe = L.openat ~sw ~mode:0 "/bin/ls" L.Open_flags.(rdonly + excl) in
  let dir = L.openat ~sw ~mode:0 "/etc" L.Open_flags.(rdonly + directory + excl) in
  let pid = L.spawn ~sw L.Fork_action.[
      fchdir dir;
      execat exe [| "ls"; "-l" |];
    ] in
  traceln "spawned PID %d" pid

Probably some of this could go in Eio_unix and be shared between the various backends.

Fork_actions could also be expanded to include privilege dropping syscalls for the subprocess too, which is rather neat. E.g. a call to Fork_action.pledge in a future Eio_openbsd :-)

Cool API. The idea here is that you can have arbitrarily complicated lists of actions right? The example is a simple case that I think (at least in my mind) is easier to understand/code with something like what we have i.e. spawn ~cwd:dir "ls" but we have no nice way to say chdir; exec; chdir; exec inside the same fork. Similarly with pledge you might want to only pledge after doing something else first and this gives you control over that ordering. Seems like a good idea, and you could certainly implement the current API on top of this! I don't know in practice how shareable the actions will be across OSes... my experience thus far is to be wary of subtleties but something like fchdir should work.

Do you think the Fork_action.t list is the right abstraction? Or should this be more abstract and more of a DSL to combine actions in some meaningful way? I'm really just thinking out loud at this point but it might be nice to be able to do something like pipe (exec foo) (exec bar) although again that could probably be built on top if this anyway...

Not quite sure where to go from here, experiment with this API first porting more of the spawn code to this modular approach?

The example is a simple case that I think (at least in my mind) is easier to understand/code with something like what we have i.e. spawn ~cwd:dir "ls"

Yes, I'd expect the high-level API to build this up for you.

but we have no nice way to say chdir; exec; chdir; exec inside the same fork.

You can't do anything after exec (well, unless it fails, I guess). But things that might be useful include:

• Reassigning FDs.
• Dropping privileges (pledge etc, as Anil mentioned), which each platform does differently.
• Setting up container namespaces.
• Changing directory (with chdir or fchdir).
• Maybe progress group stuff? Signal masks?
• Execing with execve or execveat.

And being able to do this with fork, vfork or clone3.

I'm really just thinking out loud at this point but it might be nice to be able to do something like pipe (exec foo) (exec bar) although again that could probably be built on top if this anyway...

I think that would be built on top. This API is just for stuff that can only happen after forking, where we can't use OCaml.

Not quite sure where to go from here, experiment with this API first porting more of the spawn code to this modular approach?

Yes, I think so. I can try to clean it up over the next couple of days. Do you want to try putting the higher-level API on top after that?

I currently have a problem where there are some syscalls I need to make after forking but before execing. This is to set up a PTY for the child process. I've got a branch using this PR at the moment, but without the PTY setup. While writing a C wrapper could work, I think @talex5's proposal would provide a good solution for this.

Yes, I think so. I can try to clean it up over the next couple of days. Do you want to try putting the higher-level API on top after that?

Sounds good to me :))

Closing in favour of #472 :))