Re: [Threads-devel] unbind passed function to the thread constructor after real thread exits

Subject: Re: [Threads-devel] unbind passed function to the thread constructor after real thread exits
From: Anthony Williams (anthony_at_[hidden])
Date: 2009-02-21 06:25:40

At Fri 20 Feb 2009 08:46:34 UTC, dadrus_at_[hidden] wrote:

>> BTW, which platform/compiler are you using?
> System is Windows XP Pro SP3 on 2 core pentium
> Compiler is MS VS 2005 with latest SP
>
>> What does the attached code do on your system?
>> That is bizarre. When I try the attached code it works as expected:
>> once the shared_ptr is reset, the instance is destroyed.
>
> class foo {
> public:
>   ~foo() {
>   } // break point 2
>
>   void func(int arg1) {
>     // do something
>   } // break point 1
> };
>
> int main() {
>
>   boost::shared_ptr<foo> f(new foo());
>   boost::thread t(boost::bind(&foo::func, f, 1));
>
>   getchar();
>
>   t.join(); // break point 3
>
>   f.reset();
>
>   return 0;
> }
>
> The getchar() call is just for debugging waiting purposes. So i'me   
> sure thread of execution exit.
>
> when you get to the break point 3 and do not step over there are   
> still 2 reference to foo, although the real thread of execution   
> exit. And as long as t.join() is not called the provided thread   
> function is not unbinded.
> In my opinion the function unbinding should be within the call of   
> run_thread_exit_callbacks() and not when join is called.

That's just not how the library works. The function is destroyed along  
with the remainder of the thread's resources when the thread has  
completed and the thread has been joined or detached.

> In my real code i'm using thread_pool which is a member of a   
> controller class. This one manages coming and gone instances of   
> "foo"-like objects, notifies some listeners interested in   
> corresponding events and so on. During the lifetime of a programm   
> there are a lot of such "foo" objects created and invalidated   
> (removed from the managed list; curresponding thread is interrupted   
> end exits). However joining on threads is done within a destructor   
> of the controller (on programm exit). So if there where 100 objects   
> of foo created during the program lifetime and just one is valid on   
> programm exit i've 99 corpses which still use system resources   
> (ports, sockets and so on).

OK, I see the problem. It's just not how the library is designed.

Anthony
-- 
Anthony Williams
Author of C++ Concurrency in Action | http://www.manning.com/williams
just::thread C++0x thread library   | http://www.stdthread.co.uk
Custom Software Development         | http://www.justsoftwaresolutions.co.uk
Just Software Solutions Ltd, Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK