On Thu, Jan 15, 2009 at 11:55 AM, Jim Roskind <[email protected]> wrote: > IMO, the big grouping distinction for startup code is a) code that needs to > be performed while single threaded; vs b) code that can run while > multi-threaded.
Agreed--but often (a) is used as a proxy for an ordering constraint on code that's actually (b). Documenting ordering constraints is good; implementing them in code would be even better (assert/DCHECK would be a good start, but code that actually does the ordering would be even better). Apple did a great job of this a few revs back of Mac OS X when they made most of the OS boot in parallel--each module and driver is tagged with what it depends on rather than insisting on being in a single place in a single-threaded "startup" routine or script, and the startup code orders them at runtime. It seems like we could do something similar for application startup--a middle ground between "initialize everything sequentially in a single thread" and "initialize everything lazily". --Amanda --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
