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 -~----------~----~----~----~------~----~------~--~---
