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

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-08-06 11:45:51

On Fri, 06 Aug 2004 12:06:37 -0400 Michael Glassford <glassfordm_at_[hidden]> 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 problem.
> >>
> > 
> > 
> > Thank you, I will try this.

You didn't yet check this in did you?
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 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.

> 
> 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.

Roland