--- In Boost-Users@y..., "giltayar"
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