www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Daemon Threads

reply David <d dav1d.de> writes:
I have a threaded connection:


class ThreadedConnection : Connection {
     protected Thread _thread = null;
      property Thread thread() { return _thread; }

     void run() {
         if(_thread is null) {
             _thread = new Thread(&(super.run));
             _thread.isDaemon = true;
         }

         _thread.start();
     }
}


The thread will call &super.run:

     void run() {
         while(_connected) {
             poll();
         }
     }


Since this is a daemon thread, I'd expect it to stop/terminate when the 
main thread stops. This is not the case (it keeps running), is this a 
known bug and how can I workaround this?

It also seems that it keeps running, even if I close the connection and 
super.run stops.
Aug 07 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Aug 7, 2012, at 9:36 AM, David <d dav1d.de> wrote:


 I have a threaded connection:
 ...
 Since this is a daemon thread, I'd expect it to stop/terminate when =


the main thread stops. This is not the case (it keeps running), is this =
a known bug and how can I workaround this?

Daemon threads will keep running until the process terminates.  Forcibly =
halting them any earlier risks leaving mutexes they hold in a locked =
state, etc, which could break shutdown and hang the app.  Typically, =
you'll want to have a shared module dtor communicate to any daemon =
threads that it's time for them to halt, and block until a response is =
received if you want to ensure a clean shutdown.=
Aug 07 2012
next sibling parent reply David <d dav1d.de> writes:
 Daemon threads will keep running until the process terminates.Forcibly halting
them any earlier risks leaving mutexes they hold in a 


locked state, etc, which could break shutdown and hang the app. 
Typically, you'll want to have a shared module dtor communicate to any 
daemon threads that it's time for them to halt, and block until a 
response is received if you want to ensure a clean shutdown.

Ok, so it's not like e.g. in Python, if the main thread terminates, all 
daemons die and the process exits?

Let's say I have a static shared dtor, which communicates to all 
daemons, hey you have to shutdown, now! But what happens if an exception 
is thrown, will the dtor still be called? And how would you communicate 
with the different threads?
Aug 07 2012
parent Sean Kelly <sean invisibleduck.org> writes:
On Aug 7, 2012, at 4:01 PM, David <d dav1d.de> wrote:


 Daemon threads will keep running until the process =




terminates.Forcibly halting them any earlier risks leaving mutexes they =
hold in a=20

 locked state, etc, which could break shutdown and hang the app. =


Typically, you'll want to have a shared module dtor communicate to any =
daemon threads that it's time for them to halt, and block until a =
response is received if you want to ensure a clean shutdown.

=20
 Ok, so it's not like e.g. in Python, if the main thread terminates, =


all daemons die and the process exits?

=20
 Let's say I have a static shared dtor, which communicates to all =


daemons, hey you have to shutdown, now! But what happens if an exception =
is thrown, will the dtor still be called? And how would you communicate =
with the different threads?

The basic shutdown process is:

1. Wait for all non-daemon threads to complete.
2. Run static dtors.
3. Terminate the GC.
4. Exit.

We let the OS kill any daemon threads when the process exits.  We could =
forcibly terminate them after step 3, but it amounts to the same thing.=
Aug 07 2012
prev sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:
On 07-08-2012 21:38, Sean Kelly wrote:

 On Aug 7, 2012, at 9:36 AM, David <d dav1d.de> wrote:


 I have a threaded connection:
 ...
 Since this is a daemon thread, I'd expect it to stop/terminate when the main
thread stops. This is not the case (it keeps running), is this a known bug and
how can I workaround this?


 Daemon threads will keep running until the process terminates.  Forcibly
halting them any earlier risks leaving mutexes they hold in a locked state,
etc, which could break shutdown and hang the app.  Typically, you'll want to
have a shared module dtor communicate to any daemon threads that it's time for
them to halt, and block until a response is received if you want to ensure a
clean shutdown.


Huh? From thread.di:

     /**
      * Gets the daemon status for this thread.  While the runtime will 
wait for
      * all normal threads to complete before tearing down the process, 
daemon
      * threads are effectively ignored and thus will not prevent the 
process
      * from terminating.  In effect, daemon threads will be terminated
      * automatically by the OS when the process exits.
      *
      * Returns:
      *  true if this is a daemon thread.
      */
     final  property bool isDaemon();

I'm confused... shouldn't daemon threads die when the main thread dies 
(which effectively exits the process)?

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Aug 07 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Aug 7, 2012, at 5:41 PM, Alex R=F8nne Petersen <alex lycus.org> =
wrote:


 On 07-08-2012 21:38, Sean Kelly wrote:

 On Aug 7, 2012, at 9:36 AM, David <d dav1d.de> wrote:
=20

 I have a threaded connection:
 ...
 Since this is a daemon thread, I'd expect it to stop/terminate when =






the main thread stops. This is not the case (it keeps running), is this =
a known bug and how can I workaround this?

=20
 Daemon threads will keep running until the process terminates.  =




Forcibly halting them any earlier risks leaving mutexes they hold in a =
locked state, etc, which could break shutdown and hang the app.  =
Typically, you'll want to have a shared module dtor communicate to any =
daemon threads that it's time for them to halt, and block until a =
response is received if you want to ensure a clean shutdown.

=20


=20
 Huh? =46rom thread.di:
=20
    /**
     * Gets the daemon status for this thread.  While the runtime will =


wait for

     * all normal threads to complete before tearing down the process, =


daemon

     * threads are effectively ignored and thus will not prevent the =


process

     * from terminating.  In effect, daemon threads will be terminated
     * automatically by the OS when the process exits.
     *
     * Returns:
     *  true if this is a daemon thread.
     */
    final  property bool isDaemon();
=20
 I'm confused... shouldn't daemon threads die when the main thread dies =


(which effectively exits the process)?

Yes, but remember that the main thread doesn't die the moment the app's =
main() function returns.  There's some runtime shutdown code that's run =
first.  See druntime/rt/dmain2.d.=
Aug 07 2012
parent reply David <d dav1d.de> writes:
 Yes, but remember that the main thread doesn't die the moment the app's main()
function returns.  There's some runtime shutdown code that's run first.  See
druntime/rt/dmain2.d.


So in my case, the main thread hangs up in the runtime? great …
Aug 08 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Aug 8, 2012, at 8:33 AM, David <d dav1d.de> wrote:


 Yes, but remember that the main thread doesn't die the moment the =




app's main() function returns.  There's some runtime shutdown code =
that's run first.  See druntime/rt/dmain2.d.

=20
 So in my case, the main thread hangs up in the runtime? great =85


C/C++ works exactly the same way.  When a C/C++ app's main() function =
exits, various cleanup tasks are run before the process itself =
terminates.  Dtors of static objects are run, exit hooks are called, =
etc.  In effect, all kernel threads are daemon threads, and D provides =
the option to get this behavior when it's necessary.  But if you have a =
daemon thread and want it to shutdown cleanly you need to take steps to =
do so.

I suppose it's worth noting that if you use std.concurrency, this is all =
taken care of for you.  Any thread spawned by the main thread will =
automatically get an OwnerTerminated or LinkTerminated message as soon =
as that app's main() routine exits, so the next time they do a receive() =
an exception will be thrown and they'll terminate cleanly.  Are you sure =
you need to use core.thread here?=
Aug 08 2012
parent David <d dav1d.de> writes:
Am 08.08.2012 20:26, schrieb Sean Kelly:

 On Aug 8, 2012, at 8:33 AM, David <d dav1d.de> wrote:


 Yes, but remember that the main thread doesn't die the moment the app's main()
function returns.  There's some runtime shutdown code that's run first.  See
druntime/rt/dmain2.d.


 So in my case, the main thread hangs up in the runtime? great …


 C/C++ works exactly the same way.  When a C/C++ app's main() function exits,
various cleanup tasks are run before the process itself terminates.  Dtors of
static objects are run, exit hooks are called, etc.  In effect, all kernel
threads are daemon threads, and D provides the option to get this behavior when
it's necessary.  But if you have a daemon thread and want it to shutdown
cleanly you need to take steps to do so.

 I suppose it's worth noting that if you use std.concurrency, this is all taken
care of for you.  Any thread spawned by the main thread will automatically get
an OwnerTerminated or LinkTerminated message as soon as that app's main()
routine exits, so the next time they do a receive() an exception will be thrown
and they'll terminate cleanly.  Are you sure you need to use core.thread here?


But I don't need the funtionallity of std.concurrency, should I use it 
anyways?
Aug 08 2012