On Thursday, 25 August 2016 at 14:53:30 UTC, Shachar Shemesh wrote:
On 25/08/16 11:46, FreeSlave wrote:
On Thursday, 25 August 2016 at 07:32:29 UTC, Shachar Shemesh wrote:
On 24/08/16 14:04, FreeSlave wrote:
Are there plans on adding something like spawnProcessDetached that would start processes completely independent from parent? I.e. in other
process group and, what is important, with no need for wait.

On Posix that could be done via double fork technique. Not sure about
Windows.

Double fork on Posix is, usually, used for something slightly
different. In particular, since you bring up the process group, I
think you mean daemonization.

Daemonization, however, does a bit more than create a new process
group and double forking.

http://forum.dlang.org/thread/[email protected] has
discussion and some code regarding this issue.

Shachar

It's not about daemonization only. Different process group is needed to prevent signal distribution. Again, e.g. file manager and launched
application may want to not be connected in any way.

Yes, that's part of daemonization. So is chdir somewhere else and closing all open file descriptors, including stdin/out/err.

http://0pointer.de/public/systemd-man/daemon.html#SysV%20Daemons

It's part of daemonization, but again, I'm not talking specifically about daemons. I'm talking about spawning of detached process (you may think about it as daemonization, but with less/different requirements)

Of course chdir and file descriptors should be configurable.

E.g. file managers usually set working directory of process to the path of executable.

When launching usual applications it's better to not close standard file descriptors, but redirect them to /dev/null, since real closing may break some apps.

Currently spawnProcess allows to set working directory and fds, but it implies you call wait afterwards. It would be cool if standard library provided the way to spawn process without worrying about zombies. And yes, with enough options it could provide support for full daemonization too (i.e. including closing standard fds).

Reply via email to