Re: Thread destruction in boost

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-05-14 16:49:38

--- In Boost-Users_at_y..., "giltayar" <gil_at_t...> wrote:
> From boost:thread documentation, it is clear that deleting a thread 
> does not kill the thread. I very much approve of this. killing a 
> thread is a very "strong" operation.
> 
> The problem is that there is now no connection between the system 
> thread and the object itself, which (debatably) kills the idiom in 
> C++ connection the object and the resource (I never remember its 
> name).
> 
> Was the idea of doing a "join()" in the dtor brought up? I.e., the 
> dtor waiting for the thread to finish? I used it in my library, and 
> it was _very_ effective, as I could _know_ that the thread and the 
> object have parallel lifetimes, and it also helped me because it 
> prevented many "thread-leakage" problems.

Yes, but I'm not convinced it's appropriate.  It would rarely be 
appropriate for a default constructed thread object (as in a self 
referencing thread object).  In fact, unless you either make "join" 
callable multiple times (which was also suggested and hotly debated) 
and/or give some mechanism for a thread(func) constructed thread 
object to turn off the call in the destructor then it would *never* 
be possible for a default constructed thread object to call "join" in 
the destructor.

Failing to call join() explicitly does not create a thread "leak".  
The thread is detached and clean up occurs according to those rules.  
The only problem is that if the main thread exits such detached 
threads may be immediately terminated (I say may, because most 
platforms have a "thread_exit" routine that prevents this from 
happening... any running threads must complete before the main thread 
returns from this call).

I know this isn't the best solution, and this is specifically one of 
the areas I'm working on for the next release of Boost.Threads (as 
opposed to the next release(s) of Boost, which will contain only bug 
fixes).

Bill Kempf