Boost logo

Boost :

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-08-06 12:56:34

"Roland" <roland.schwarz_at_[hidden]> wrote in message
> 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
> > whenever cleanup handlers are being run.
> >
> > >>I've adjusted the area where the mutex is locked to fix this
> > >>
> > >
> > >
> > > 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?

Yes, unfortunately it is.

> > 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
> main thread) have called their on_thread_exit handlers, before
> 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
> we simply need to destroy the shared tss_data when the last
> of tss has gone. I think this could work similar to the reference
> you already have implemented in tss_hooks for the exit handler

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
> > problem (already fixed)--or how reference counting would fix it.
> I meant the leakage problem.



Boost list run by bdawes at, gregod at, cpdaniel at, john at