I think we should have a list of low-level functionality which we just never cleanup.
For the items you listed, I think you should leak them all. Trying to cleanup these items creates complicated code and ultimately won't run any better and possibly slower. Mike On Fri, Nov 20, 2009 at 1:44 PM, Paweł Hajdan Jr. <phajdan...@chromium.org>wrote: > Do you have some idea how to get rid of the Singletons in base/time_win.cc? > They don't play very well with base::SystemMonitor, MessageLoop, and test > code. > > Here's the scenario we're hitting right now (in browser_tests): > > 1. HighResolutionTimerManager is created to enable high resolution timer > unconditionally. An AtExit callback is created to destroy it. > 2. The main MessageLoop is created. Its LazyInstance initializes a > ThreadLocalPointer, which gets assigned the pointer to the MessageLoop. An > AtExit callback is registered to reset the LazyInstance to the initial > state. > 3. BrowserMain enables monitoring SystemMonitor in > HighResolutionTimerManager. > 4. Which makes HighResolutionTimerManager register as a SystemMonitor > observer. > > If everything seems OK so far, you're almost right. It's perfectly fine > when browser runs, but has surprising "special effects" when test code runs. > Here's what happens: > > 1. MessageLoop is destroyed. Its ThreadLocalPointer is set to NULL. > 2. AtExit callbacks start to execute. > 3. HighResolutionTimerManager is destroyed first. Its StopMonitoring method > is called from dtor, which in turn touches MessageLoop::current(), which > touches LazyInstance and makes it re-initialize itself, which registers > AtExit callbacks which causes a DCHECK failure, because we're already > processing AtExit callbacks. > > Don't worry too much if the explanation above is unclear (I'm afraid it > is). The point is, it's not the first time that a nasty bug happens with > SystemMonitor and the time_win.cc Singletons. Earlier it was different, so > it's not so much important in what particular way it failed now. > > I'd really love to get rid of these Singletons. Do you have any ideas? We > have two things here: > > 1) NowSingleton which keeps track of Windows time rollover. This might be > harder to remove, but isn't causing too many problems. > 2) HighResolutionTimerManager is causing problems. It was previously part > of NowSingleton. I extracted the most evil part of it, and this is the > current HRTM. I'm thinking about hardwiring it with the SystemMonitor or > making it a Leaky Singleton maybe... > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
