[boost] Re: [boost.thread] at_thread_exit must be serialized?

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-08-06 11:06:37

Roland wrote:

> On Fri, 06 Aug 2004 11:31:08 -0400 Michael Glassford <glassfordm_at_[hidden]> wrote:
> 
> 
>>They don't; the mutex is to protect access to other global variables. 
>>Most of them were experimental and have been eliminated, but there's 
>>still one important one left: tls_key.
> 
> 
> I am afraid in the meantime I did find another reason why (but I think its not a serious one):
> at_thread_exit may not access the list while the handlers are running. But this is
> odd usage anyways, isn't it?

The change I made should fix this case, too. The mutex is now unlocked 
whenever cleanup handlers are being run.

>>I've adjusted the area where the mutex is locked to fix this problem.
>>
> 
> 
> Thank you, I will try this.
> 
> BTW.: I am still thinking about the leakage problem:
> 
> I tried to forcibly allocate/deallocate the tss_data pointer, but MFC still
> shows leakage. I think I know very well why. So the on_process_init/
> on_process_term idea was not of use in this case.

Is it possible that MFC is running its leak check before the code 
releasing everything is run?

> In the meantime I had another thought:
> Do you think the problem could be solved by refernce counting: say using
> a shared_ptr ?

Sorry, I'm not sure which problem you mean--the leak or the recursion 
problem (already fixed)--or how reference counting would fix it.

Mike