Deno: Detached processes in deno

[manikawnth]

Currently node has the capability to run a child process in detached mode (setsid()), which is lacking in deno (?)

It seems the Tokio Command doesn't expose any specific functionality for this.
Is it possible for Deno to provide this functionality?

Also, this specific default (kill if handle is dropped from the scope) in rust std and tokio is overridden in Deno (cli/ops/process.rs). Is that related to detached mode?

fn op_run(...) {
     ....
    // We want to kill child when it's closed
    c.kill_on_drop(true);
}

Is there a better place to ask such questions than cluttering the issues section?

[ry]

Correct, Deno does not have this functionality yet. I would be happy to add it.

Let's figure out what the JS API should look like. We try to not randomly invent new APIs, but instead look at how Node, Go, Rust, Python have exposed it and see if we can use the most common nomenclatures. Would you mind researching this? This would help move the feature forward.

Is there a better place to ask such questions than cluttering the issues section?

This is the right place for a feature request.

[manikawnth]

Firstly Deno has done the right thing by not making detached as default, 'coz that's the default nature of both win API and posix API

C has the cleanest way of not having anything in language and having OS specific APIs

Node has flat argument structure. while detached and shell are applicable to both OSs, uid and gid of unix are generally exposed which throws a ENOTSUP (not supported) error on non-supported platforms like windows

go has syscall.StartProcess() which has separate SysProcAttr structs for each OS. It took the correct route of freezing syscall package and delegating it to sys/ specific package. But it has a real low-level interface for spawning, like doing Syscall(SYS_FORK..) then do Setsid() and then Exec(...) which is right way. Windows has a fairly easy parameterized CreateProcess(...)

Python's subprocess is intended to replace old os.spawn() and they've similar function signature subprocess.run(...) as Deno. The Popen(...) constructor has start_new_session which is similar to setsid, but it's applicable only for Linux. Windows users have to create a separate STARTUPINFO object for all process creation parameters

Rust took the c route of not having anything directly interfaced but left to users via OS specific extension traits (impl CommandExt for Command)
All langugages have moved/moving towards either OS specific interfaces or configurations,

Largely I can think of two options:

1. Like Node, keep a flat option structure and throw "Not supported" error as the developer should really know what he's doing. Or
2. Pass the OS specific config similar to Python, e.g. like a Typescript either/or type and all the OS specific variables to be interfaced under Deno namespace. This way we can do clean check across using Deno.build.os. Pseudo-syntax:
   type ProcessOpts = Deno.WinOpts.process | Deno.UnixOpts.process

[buckle2000]

How useful is this feature? You can always spawn a separate process by running the script again with different arguments. It would be hard to design security around this.

[manikawnth]

Detachment is just one aspect of it. The sub-process creation also has setting uid, gids to the process, which is needed, if we're looking deno as potential replacement for bash and python.

And moreover underlying rust is handling it cleanly, so it's a matter of exposing it with a neat interface.