Another problem with moving everything out of browserinit is unit tests. It's much easier for unit tests to call a single function to startup and one for shutdown instead of having to call out to a bunch of services to explicitly shut them down.
-Scott On Wed, Jan 14, 2009 at 11:34 PM, Darin Fisher <[email protected]> wrote: > the winsock initialization can be removed now that we have EnsureWinSockInit > which should be called by any code that uses winsock. (we may not have > sprinkled that in all of the right places, but you get the idea.) > i really like your idea of documenting startup dependencies, and i agree > that the reason for a lot of this is to deal with required orderings. if we > were to try to make everything lazily init via Singleton or function > statics, we'd then potentially have shutdown ordering problems as we also > have to be careful about the order in which things get torn down. sometimes > it is just better to lay things out carefully at startup and shutdown > instead of trying to do everything in a cleverly lazy fashion. of course > that doesn't work if startup (and shutdown) are treated like dumping grounds > as has been the case :-( > > -darin > > On Wed, Jan 14, 2009 at 3:08 AM, Dean McNamee <[email protected]> wrote: >> >> +1, when working on startup performance, I had a really difficult time >> following the startup sequence from the code. I actually relied more >> on the generated traces to know what was going on. Additionally, >> since nothing was commented, and all ordering seemed arbitrary, it was >> hard to tell if things were scheduled at a certain place for a reason, >> if the could be moved around to help startup perf, etc. >> >> It would be great at least if every piece of initialization code could >> have a comment that states what it's initializing, and what it depends >> on having been already initialized, etc. This would then help the >> second pass of moving the minor initialization where scheduling isn't >> important into better places... >> >> It is also probably currently a mess for cross platform, for example, >> we were initializing winsock in browsermain, which to me seems >> completely unrelated to this portion of code. >> >> On Wed, Jan 14, 2009 at 9:11 AM, Peter Kasting <[email protected]> >> wrote: >> > On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) >> > <[email protected]> >> > wrote: >> >> >> >> It looks like everyone and their dog adds init code to the startup >> >> sequence. This takes the form of first time initialization, command >> >> line switch parsing, etc. Is there any special reason why it's done in >> >> the startup flow vs. in a static method the first time a service is >> >> created or used? >> > >> > All I know is there are lots of ordering dependencies, where certain >> > classes >> > must be initialized before others. Most of these are subtle and >> > undocumented :( >> > Even besides the methods you named, there are a slew of other >> > initialization >> > methods whose purpose is wildly unclear. When adding support for >> > --user-agent=, I tried to understand some of this stuff better with >> > jam's >> > help and came to the conclusion that a lot of it was insane and should >> > be >> > condensed, redesigned entirely, etc. If you're cleaning up startup, >> > definitely also look at the methods I touched when adding that switch >> > too (a >> > lot of them might be better places for stuff that lives in BrowserMain). >> > PK >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
