From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-08-06 11:06:37
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk