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.
The first group effectively replaced the Google-style-illegal global static
initializers, and allows slight variation of ordering between
On Thu, Jan 15, 2009 at 11:55 AM, Jim Roskind j...@chromium.org 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
I'm not coming at this from an optimization perspective, I'm thinking
more of making the startup flow understandable to mere mortals. Sadly
the sequence now is complex enough that people are jamming in their
init code wherever because by all appearances that's what everyone
else has done. I
On Thu, Jan 15, 2009 at 11:11 AM, Ben Goodger (Google) b...@chromium.org
wrote:
I'm not coming at this from an optimization perspective, I'm thinking
more of making the startup flow understandable to mere mortals.
Amanda's suggestion would likely actually accomplish both, so I don't
think we
That's true. In the example I gave (Mac driver loading), each module
has a property list that lists its dependencies (and version
requirements, etc.). That's not quite as simple to do inside a single
application, of course, but having code do the ordering still seems
like a win to me.
Consider
On Thu, Jan 15, 2009 at 1:19 PM, Amanda Walker ama...@chromium.org wrote:
That's true. In the example I gave (Mac driver loading), each module
has a property list that lists its dependencies (and version
requirements, etc.). That's not quite as simple to do inside a single
application, of
I don't know how many interdependencies we have--I was relying on
ben's everyone and their dog assessment :-). That said, I write a
makefile (or equivalent) for anything with 2 source files, so writing
the dependencies in code rather than comments doesn't strike me as a
large cost.
--Amanda
Here's my plan. The Mac and Linux people are probably going to proceed
just by using ifdefs to get the startup sequence up and running, but
in the process learn more about what goes on where. We can first split
into separate phase functions for readability, and then after that
figure out if any
Separate phase functions sounds good to me. We should make it clear that
stuff within a phase should not be interdependent, but that might be hard to
verify and enforce :-/
-Darin
On Thu, Jan 15, 2009 at 2:18 PM, Ben Goodger (Google) b...@chromium.orgwrote:
Here's my plan. The Mac and Linux
On Thu, Jan 15, 2009 at 3:06 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay erik...@chromium.org wrote:
The issue is one of maintenance. A lot happens at startup. As people
make changes, it's not necessarily obvious where to insert your
On Thu, Jan 15, 2009 at 3:06 PM, Brett Wilson bre...@chromium.org wrote:
On Thu, Jan 15, 2009 at 2:06 PM, Erik Kay erik...@chromium.org wrote:
The issue is one of maintenance. A lot happens at startup. As people
make changes, it's not necessarily obvious where to insert your
initialization
On Tue, Jan 13, 2009 at 11:56 PM, Ben Goodger (Google) b...@chromium.orgwrote:
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
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
13 matches
Mail list logo
