|
Boost : |
From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-08-06 12:56:34
"Roland" <roland.schwarz_at_[hidden]> wrote in message
news:20040806164129.GBDQ9307.viefep19-int.chello.at_at_speedsnail...
> 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?
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk