If I use core.thread.Thread to create a new thread associated to a function like this:

Thread testThread = new Thread(&DoSomething);

Will the testThread dispose of itself after DoSomething() completes, or do I need to join/destroy/somethingelse testThread?

On 07/20/2013 12:34 PM, Alex Horvat wrote:

> If I use core.thread.Thread to create a new thread associated to a
> function like this:
>
> Thread testThread = new Thread(&DoSomething);
>
> Will the testThread dispose of itself after DoSomething() completes, or
> do I need to join/destroy/somethingelse testThread?

When the execution of the thread finishes, you will end up with a completed thread:

import std.stdio;
import core.thread;

void DoSomething()
{
    writeln("Doing something...");
}

void main()
{
    auto thread = new Thread(&DoSomething);
    thread.start();

    thread_joinAll();

    assert(!thread.isRunning);    // <-- Not running
}

You do not need to do anything with the object. In fact, the documentation says that you shouldn't delete it: "instances of this class should never be explicitly deleted". ('delete' is gone, so it should mean that you shouldn't destroy() it.)

Ali

On Saturday, 20 July 2013 at 20:36:29 UTC, Ali Çehreli wrote:
> On 07/20/2013 12:34 PM, Alex Horvat wrote:
>
> > If I use core.thread.Thread to create a new thread associated
> to a
> > function like this:
> >
> > Thread testThread = new Thread(&DoSomething);
> >
> > Will the testThread dispose of itself after DoSomething()
> completes, or
> > do I need to join/destroy/somethingelse testThread?
>
> When the execution of the thread finishes, you will end up with a completed thread:
>
> import std.stdio;
> import core.thread;
>
> void DoSomething()
> {
>     writeln("Doing something...");
> }
>
> void main()
> {
>     auto thread = new Thread(&DoSomething);
>     thread.start();
>
>     thread_joinAll();
>
>     assert(!thread.isRunning);    // <-- Not running
> }
>
> You do not need to do anything with the object. In fact, the documentation says that you shouldn't delete it: "instances of this class should never be explicitly deleted". ('delete' is gone, so it should mean that you shouldn't destroy() it.)
>
> Ali

Thanks.

What happens if I don't call thread join? (My thread is just a timer to hide a bit of text, so I just create it, forget about it and continue with the main thread)
Will the thread still dispose of itself in this situation?

On 07/20/2013 06:04 PM, Alex Horvat wrote:

> On Saturday, 20 July 2013 at 20:36:29 UTC, Ali Çehreli wrote:

>>     thread_joinAll();

> What happens if I don't call thread join? (My thread is just a timer to
> hide a bit of text, so I just create it, forget about it and continue
> with the main thread)
> Will the thread still dispose of itself in this situation?

When the parent thread terminates the child processes terminate as well. Join is only for when the parent wants to wait for the child to finish.

Ali

On 07/20/2013 09:43 PM, Ali Çehreli wrote:

> When the parent thread terminates the child processes terminate as well.

I am wrong there: What I said above is true for the main program thread. When the main program terminates, its threads are terminated as well.

Otherwise, a child can continue running even though its parent (owner) has terminated. This is evidenced by the fact that std.concurrency has an exception named OwnerTerminated, useful for the child.

Ali

On Sunday, 21 July 2013 at 15:30:06 UTC, Ali Çehreli wrote:
> On 07/20/2013 09:43 PM, Ali Çehreli wrote:
>
> > When the parent thread terminates the child processes
> terminate as well.
>
> I am wrong there: What I said above is true for the main program thread. When the main program terminates, its threads are terminated as well.
>
> Otherwise, a child can continue running even though its parent (owner) has terminated. This is evidenced by the fact that std.concurrency has an exception named OwnerTerminated, useful for the child.
>
> Ali

Thanks again, but I feel I need to give more details - what I really want to know is if what I'm doing will cause a memory leak by leaving a child thread going - the parent thread won't exit until the program is closed.

The program is loading a video onto a gtkOverlay widget, then overlaying a label to display the name of the video. Once the label is displayed a thread is created, which waits 3 seconds then hides the label. After creating the thread the parent thread has nothing more to do with it.

I've included a bit more code below:

private Label _lblTitle;

public void LoadVideo()
{
  //Setting up video here....

  _lblTitle.setText("example");
  _lblTitle.show();

  //Spawn a new thread to hide the title
  Thread TitleHider = new Thread(&DelayedHideTitle);
  TitleHider.start();

  //Keep going on main thread...
}

private void DelayedHideTitle()
{
  Thread.sleep(dur!"seconds"(3));
  _lblTitle.hide();
}

DelayedHideTitle() is the entire contents of the child thread, after the method finishes does the thread TitleHider dispose of itself?

On 07/22/2013 08:32 AM, Alex Horvat wrote:
> On Sunday, 21 July 2013 at 15:30:06 UTC, Ali Çehreli wrote:
>> On 07/20/2013 09:43 PM, Ali Çehreli wrote:
>>
>> > When the parent thread terminates the child processes
>> terminate as well.
>>
>> I am wrong there: What I said above is true for the main program
>> thread. When the main program terminates, its threads are terminated
>> as well.
>>
>> Otherwise, a child can continue running even though its parent (owner)
>> has terminated. This is evidenced by the fact that std.concurrency has
>> an exception named OwnerTerminated, useful for the child.
>>
>> Ali
>
> Thanks again, but I feel I need to give more details - what I really
> want to know is if what I'm doing will cause a memory leak by leaving a
> child thread going - the parent thread won't exit until the program is
> closed.
>
> The program is loading a video onto a gtkOverlay widget, then overlaying
> a label to display the name of the video. Once the label is displayed a
> thread is created, which waits 3 seconds then hides the label. After
> creating the thread the parent thread has nothing more to do with it.
>
> I've included a bit more code below:
>
> private Label _lblTitle;
>
> public void LoadVideo()
> {
>    //Setting up video here....
>
>    _lblTitle.setText("example");
>    _lblTitle.show();
>
>    //Spawn a new thread to hide the title
>    Thread TitleHider = new Thread(&DelayedHideTitle);
>    TitleHider.start();
>
>    //Keep going on main thread...
> }
>
> private void DelayedHideTitle()
> {
>    Thread.sleep(dur!"seconds"(3));
>    _lblTitle.hide();
> }
>
> DelayedHideTitle() is the entire contents of the child thread, after the
> method finishes does the thread TitleHider dispose of itself?

Unfortunately, I don't know enough to answer these questions. :(

pthread_create man page says: "Only when a terminated joinable thread has been joined are the last of its resources released back to the system.  When a detached thread terminates, its resources are auto- matically released back to the system:"

Apparently, it is possible to detach from a thread or even to start it in the detached state to begin with: "By default, a new thread is created in a joinable state, unless attr was set to create the thread in a detached state (using pthread_attr_setdetachstate(3))." But core.thread doesn't seem to provide either of those.

Ali

> ....
> When a detached thread terminates, its resources are auto- matically released back to the system:"

Sounds like I can call Thread.getThis().thread_detachThis() from within DelayedHideTitle() and that will make the thread detached and therefore it will destroy itself properly.

Or, if that doesn't work calling TitleHider.thread_detachThis() or Thread.thread_detachByAddr(TitleHider.ThreadAddr) from within LoadVideo() might work.

On Jul 20, 2013, at 12:34 PM, Alex Horvat <alexh@gmail.com> wrote:

> If I use core.thread.Thread to create a new thread associated to a function like this:
> 
> Thread testThread = new Thread(&DoSomething);
> 
> Will the testThread dispose of itself after DoSomething() completes, or do I need to join/destroy/somethingelse testThread?

The thread will clean itself up automatically if you don't hold any references to it.  In essence, the thread's dtor will conditionally release any handles if join() was never called.

On Jul 22, 2013, at 9:15 AM, Ali Çehreli <acehreli@yahoo.com> wrote:
> 
> Apparently, it is possible to detach from a thread or even to start it in the detached state to begin with: "By default, a new thread is created in a joinable state, unless attr was set to create the thread in a detached state (using pthread_attr_setdetachstate(3))." But core.thread doesn't seem to provide either of those.

Nope.  The thread can't be detached early because the GC might need to operate on the thread in some way.