On Fri, Nov 20, 2009 at 23:34, Darin Fisher da...@chromium.org wrote:
We could define a function that must be called before you can use code in
base/. You could add a call to this everywhere that we currently create the
AtExitManager. Or, maybe we could combine those somehow.
Thanks for
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
On Sun, Nov 22, 2009 at 4:28 PM, Mike Belshe mbel...@google.com wrote:
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
It's really about the unit tests, not in chromium.
I guess we could probably leak the singleton in the unit tests too on
each reset. Pawel, what do you think?
Note to all the static local makers: you create an implicit atexit()
each time... Use a leaky singleton instead.
M-A
On Sun, Nov 22,
We could define a function that must be called before you can use code in
base/. You could add a call to this everywhere that we currently create the
AtExitManager. Or, maybe we could combine those somehow.
I don't think lazy initialization of stuff like this is all that valuable.
It is
On Mon, Nov 23, 2009 at 02:22, Marc-Antoine Ruel mar...@google.com wrote:
It's really about the unit tests, not in chromium.
I guess we could probably leak the singleton in the unit tests too on
each reset. Pawel, what do you think?
Note to all the static local makers: you create an
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
