www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Do threads 'end' themselves using core.thread?

reply "Alex Horvat" <alexh gmail.com> writes:
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?
Jul 20 2013
next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jul 20 2013
parent reply "Alex Horvat" <alexh gmail.com> writes:
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?
Jul 20 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jul 20 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jul 21 2013
parent reply "Alex Horvat" <alexh gmail.com> writes:
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?
Jul 22 2013
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Jul 22 2013
next sibling parent reply "Alex Horvat" <alexh gmail.com> writes:
 ....
 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.
Jul 22 2013
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Jul 22, 2013, at 9:45 AM, "Alex Horvat" <alexh gmail.com> wrote:


 ....
 When a detached thread terminates, its resources are auto- matically =




released back to the system:"

=20
 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.

Only call thread_detachThis() if you initialized the thread object via =
thread_attachThis().  Otherwise just discard the reference and let it =
clean itself up.  The reason for the "do not delete" restriction is =
because the thread objects are tracked internally by the GC, and they =
must remain in a correct state until the GC has recognized that they =
have terminated.=
Jul 22 2013
parent reply "Alex Horvat" <alexh gmail.com> writes:
On Monday, 22 July 2013 at 16:58:00 UTC, Sean Kelly wrote:

 On Jul 22, 2013, at 9:45 AM, "Alex Horvat" <alexh gmail.com> 
 wrote:


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


 Only call thread_detachThis() if you initialized the thread 
 object via thread_attachThis().  Otherwise just discard the 
 reference and let it clean itself up.  The reason for the "do 
 not delete" restriction is because the thread objects are 
 tracked internally by the GC, and they must remain in a correct 
 state until the GC has recognized that they have terminated.


Thanks, sounds like I can just do this and the thread will clean 
itself up:

Thread TitleHider = new Thread(&DelayedHideTitle);
TitleHider.start();
TitleHider = null;
Jul 22 2013
parent Sean Kelly <sean invisibleduck.org> writes:
On Jul 22, 2013, at 10:25 AM, Alex Horvat <alexh gmail.com> wrote:


 On Monday, 22 July 2013 at 16:58:00 UTC, Sean Kelly wrote:

 On Jul 22, 2013, at 9:45 AM, "Alex Horvat" <alexh gmail.com> wrote:
=20

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

=20
 Only call thread_detachThis() if you initialized the thread object =




via thread_attachThis().  Otherwise just discard the reference and let =
it clean itself up.  The reason for the "do not delete" restriction is =
because the thread objects are tracked internally by the GC, and they =
must remain in a correct state until the GC has recognized that they =
have terminated.

=20
 Thanks, sounds like I can just do this and the thread will clean =


itself up:

=20
 Thread TitleHider =3D new Thread(&DelayedHideTitle);
 TitleHider.start();
 TitleHider =3D null;


Yep.=
Jul 22 2013
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jul 22, 2013, at 9:15 AM, Ali =C7ehreli <acehreli yahoo.com> wrote:

=20
 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.=
Jul 22 2013
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
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:

=20
 Thread testThread =3D new Thread(&DoSomething);
=20
 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.
Jul 22 2013