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.

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.

> 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?

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

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
> 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?

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.

On Aug 7, 2012, at 5:41 PM, Alex Rønne 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:
>> 
>>> 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)?

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.

> 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 …

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?

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?