www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - std.process: spawnProcess

reply Russel Winder <russel winder.org.uk> writes:
=46rom what I can see, processes created with std.process: spawnProcess are n=
ot
terminated when the creating process terminates, i.e. it seems Config.detac=
hed
is the default for these process.

Is there a way of all spawned processes being terminated on main terminatio=
n?
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 07 2018
next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:

 From what I can see, processes created with std.process: 
 spawnProcess are not terminated when the creating process 
 terminates, i.e. it seems Config.detached is the default for 
 these process.

 Is there a way of all spawned processes being terminated on 
 main termination?





void main()
{

...
auto yourpid = spawnProcess(...);
scope(exit) kill(yourpid, SIGINT); // Or SIGKILL :)
// Or: scope(exit) wait(yourpid);
...
}

Andrea
Sep 07 2018
parent Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-09-07 at 15:53 +0000, Andrea Fontana via Digitalmars-d-learn
wrote:

=20


[=E2=80=A6]

 void main()
 {
=20
 ...
 auto yourpid =3D spawnProcess(...);
 scope(exit) kill(yourpid, SIGINT); // Or SIGKILL :)
 // Or: scope(exit) wait(yourpid);
 ...
 }
=20


Nice thought, but the spawn is deep in the heart of the application, so
scope(exit) isn't feasible.

I am rapidly coming to the conclusion, that I am going to have to use a
registry and apply kill as the last act in main. :-(
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 07 2018
prev sibling next sibling parent reply Dr.No <jckj33 gmail.com> writes:
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:

 From what I can see, processes created with std.process: 
 spawnProcess are not terminated when the creating process 
 terminates, i.e. it seems Config.detached is the default for 
 these process.

 Is there a way of all spawned processes being terminated on 
 main termination?


You also can use WINAPI's job object. It will close the registred 
process, even if the application exit abruptly. I have, by now, 

convert to D easily.

https://stackoverflow.com/questions/6266820/working-example-of-createjobobject-setinformationjobobject-pinvoke-in-net
Sep 07 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-09-07 at 16:05 +0000, Dr.No via Digitalmars-d-learn wrote:

=20


[=E2=80=A6]

 You also can use WINAPI's job object. It will close the registred=20
 process, even if the application exit abruptly. I have, by now,=20

 convert to D easily.
=20
=20


https://stackoverflow.com/questions/6266820/working-example-of-createjobobj=
ect-setinformationjobobject-pinvoke-in-net

I guess this might work on Windows, but I am on Linux and OSX, so I'll have=
 to
try another route.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 07 2018
parent FreeSlave <freeslave93 gmail.com> writes:
On Friday, 7 September 2018 at 16:44:09 UTC, Russel Winder wrote:

 I guess this might work on Windows, but I am on Linux and OSX, 
 so I'll have to try another route.


On Posix systems you may try using SIGCHLD handler. Google for 
exact examples.
Sep 08 2018
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:

 From what I can see, processes created with std.process: 
 spawnProcess are not terminated when the creating process 
 terminates, i.e. it seems Config.detached is the default for 
 these process.

 Is there a way of all spawned processes being terminated on 
 main termination?


You can wrap in a Process struct or class and take advantage of 
the destructor to do that. Assuming you write standard GC-ed code 
the destructor should be called at the end or if you free 
manually the resources.

example API:

struct SpawnedProcess
{
private:
     Pid pid;
public:
     this();
     void execute();
     void terminate();
     bool running();
     ~this(){ if (running) terminate();}
}

P.S: i just see that in my own Process class i forgot to do that.
Sep 07 2018
parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2018-09-08 at 02:38 +0000, Basile B. via Digitalmars-d-learn wrote:

=20


[=E2=80=A6]

 You can wrap in a Process struct or class and take advantage of=20
 the destructor to do that. Assuming you write standard GC-ed code=20
 the destructor should be called at the end or if you free=20
 manually the resources.


But as with other GC systems, there is no guarantee that the destructor wil=
l
ever be called, or perhaps there is something here that gets round that?


 example API:
=20
 struct SpawnedProcess
 {
 private:
      Pid pid;
 public:
      this();
      void execute();
      void terminate();
      bool running();
      ~this(){ if (running) terminate();}
 }


struct or class? Given it is of necessity a heap located value I'd have use=
d
class, but is struct better here?=20


 P.S: i just see that in my own Process class i forgot to do that.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 08 2018
prev sibling next sibling parent reply FreeSlave <freeslave93 gmail.com> writes:
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:

 From what I can see, processes created with std.process: 
 spawnProcess are not terminated when the creating process 
 terminates, i.e. it seems Config.detached is the default for 
 these process.


No, detached is not default. By default you should call wait on 
processes to free OS resources. Process may stay as zombie 
otherwise and it can be visible in process manager.


 Is there a way of all spawned processes being terminated on 
 main termination?


You probably need to register all child processes. Or spawn them 
as detached so you won't need to worry about freeing them.
Sep 08 2018
parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2018-09-08 at 10:24 +0000, FreeSlave via Digitalmars-d-learn wrote:

 On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:

 From what I can see, processes created with std.process:=20
 spawnProcess are not terminated when the creating process=20
 terminates, i.e. it seems Config.detached is the default for=20
 these process.


=20
 No, detached is not default. By default you should call wait on=20
 processes to free OS resources. Process may stay as zombie=20
 otherwise and it can be visible in process manager.


Annoying but yes, it looks like having a global registry of processes has t=
o
be created so they can be killed on main termination. :-(

Though I am going to tinker with Basile B's suggestion of using a managing
object with a destructor to see if that can avoid the global registry.=20


 Is there a way of all spawned processes being terminated on=20
 main termination?


=20
 You probably need to register all child processes. Or spawn them=20
 as detached so you won't need to worry about freeing them.


Detached is not a good idea, the spawned processes should not outlive the
spawning process.
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 08 2018
prev sibling parent viniarck <viniarck gmail.com> writes:
On Friday, 7 September 2018 at 14:36:42 UTC, Russel Winder wrote:

 From what I can see, processes created with std.process: 
 spawnProcess are not terminated when the creating process 
 terminates, i.e. it seems Config.detached is the default for 
 these process.

 Is there a way of all spawned processes being terminated on 
 main termination?


On Python std lib, there's a way to daemonize a process [1]. I 
tried to accomplish something equivalent by spawning a process 
inside a daemon thread in D:

```
auto daemonizedProc() {
     import std.process;
     import std.stdio;
     auto pid = spawnProcess(["telnet"]);
     writeln(pid.processID);
}

void main() {
     import core.thread;
     auto t = new Thread(&daemonizedProc);
     t.isDaemon(true);
     t.start();
     // just to see it running for a few secs..
     Thread.sleep(10.seconds);
}
```

Based on my tests, whenever the main process exits (which is 
called "proctest" in the output bellow) the spawned process was 
terminated as a result as well, I tested on Linux:

```
~/repos/dlang master*
❯ ps -ax | egrep "telnet|proctest"
14456 pts/13   S+     0:00 ./proctest
14458 pts/13   S+     0:00 /usr/bin/telnet
14537 pts/7    S+     0:00 grep -E telnet|proctest

~/repos/dlang master*
❯ ps -ax | egrep "telnet|proctest"
14456 pts/13   S+     0:00 ./proctest
14458 pts/13   S+     0:00 /usr/bin/telnet
14633 pts/7    S+     0:00 grep -E telnet|proctest

~/repos/dlang master*
❯ ps -ax | egrep "telnet|proctest"
14731 pts/7    S+     0:00 grep -E telnet|proctest
```

[1] - 
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Process
Sep 08 2018