dynamobi-build
commented
12 years ago [author="jhyde", created="Mon, 8 Dec 2008 18:59:29 -0500 (GMT-05:00)"]
We encountered a problem where a TraceSource was not initialized, and the tracing level member variable had a random value. The effect was that the work was being done to generate tracing, but it was then going nowhere. A major CPU hog.
Jack Hahn has fixed this in change 12051. Whether or not we decide to have an explicit constructor for TraceSource, please ensure that by default tracing is OFF.
[reporter="jvs", created="Thu, 10 Aug 2006 17:23:31 -0500 (GMT-05:00)"] We use virtual inheritance for TraceSource in many places. The fact that it has a default constructor makes this into a major gotcha, because if the most-derived class does not explicitly call the constructor, and instead passes the parameters up to the superclass, the default constructor gets called instead (so no tracing gets enabled). This is currently the case for DfsTreeExecStreamScheduler; Zelaine is going to fix it.
Seems like the problem results from the fact that sometimes we want to initialize TraceSources at construction time (e.g. ExecStreamScheduler), and sometimes we want to initialize them afterwards (e.g. ExecStreams, where we definitely don't want to take constructor parameters).
One solution would be to get rid of the TraceSource constructor which takes parameters, and require TraceSource initialization to always be done via a call to initTraceSource.
Another one would be to introduce a new subclass UninitializedTraceSource (need a better name) and move the default constructor there. Then anyone inheriting TraceSource directly would be forced by the compiler to make the constructor call from all levels; classes like ExecStreams would inherit UninitializedTraceSource instead, so they wouldn't need to make any constructor call.