Thread overview
Avoid zombie processes with std.process
Aug 24, 2016
FreeSlave
Aug 24, 2016
eugene
Aug 25, 2016
FreeSlave
Sep 22, 2016
Brian
Aug 24, 2016
Basile B.
Aug 25, 2016
Shachar Shemesh
Aug 25, 2016
FreeSlave
Aug 25, 2016
Shachar Shemesh
Aug 25, 2016
FreeSlave
August 24, 2016
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.
August 24, 2016
On Wednesday, 24 August 2016 at 11:04:58 UTC, 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.

could you give some use-cases and list drawbacks of that addition?
August 24, 2016
On Wednesday, 24 August 2016 at 11:04:58 UTC, 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.

An async process is what you want.None of the D async frameworks implement this. They'are all focused on network, like if it's easyer to test /:

https://github.com/putaolabs/collie
https://github.com/dcarp/asynchronous
https://github.com/etcimon/libasync
August 25, 2016
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/d83ugn$265f$1@digitaldaemon.com has discussion and some code regarding this issue.

Shachar
August 25, 2016
On Wednesday, 24 August 2016 at 15:48:24 UTC, eugene wrote:
> On Wednesday, 24 August 2016 at 11:04:58 UTC, 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.
>
> could you give some use-cases and list drawbacks of that addition?

Use case: e.g. launch application from file manager. File manager may not care about waiting for applications to exit.

Drawbacks: why there should be one?
August 25, 2016
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/d83ugn$265f$1@digitaldaemon.com 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.
August 25, 2016
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/d83ugn$265f$1@digitaldaemon.com 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
August 25, 2016
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/d83ugn$265f$1@digitaldaemon.com 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).
September 22, 2016
On Wednesday, 24 August 2016 at 15:48:24 UTC, eugene wrote:
> On Wednesday, 24 August 2016 at 11:04:58 UTC, 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.
>
> could you give some use-cases and list drawbacks of that addition?

collie ( https://github.com/putaolabs/collie ):
An asynchronous event-driven network framework written in D.
I'm sure you will like it :)