On Fri, 06 Aug 2004 12:06:37 -0400 Michael Glassford <glassfordm@hotmail.com> wrote:
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
"Roland" <roland.schwarz@chello.at> wrote in message news:20040806164129.GBDQ9307.viefep19-int.chello.at@speedsnail... problem.
Thank you, I will try this.
You didn't yet check this in did you?
Yes, I did.
Or could it be, that the anonymous CVS access is skewed in time?
Is it possible that MFC is running its leak check before the code releasing everything is run?
I think this is the case. The leak-check ca nbe seen to be triggered by a global destructor call of a process object. So it isn't obvious when the releasing code should be run. But if we can count on the prerequisite that any threads (including
Yes, unfortunately it is. the
main thread) have called their on_thread_exit handlers, before global dtors are beeing run, only a single threaded problem remains. I think this can be tackled then by reference counting. Because the leak checker of MFC has to be correct for global objects, we simply need to destroy the shared tss_data when the last destructor of tss has gone. I think this could work similar to the reference counting you already have implemented in tss_hooks for the exit handler chain.
Which I've since pretty much removed. It seemed unnecessary and perhaps unreliable. It also had the problem of freeing too often: if you created a thread that used tss, then it exited, then you created another, then it exited, etc., TlsAlloc and TlsFree would be called over and over again.
Sorry, I'm not sure which problem you mean--the leak or the recursion problem (already fixed)--or how reference counting would fix it.
I meant the leakage problem.
OK. Mike