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
