Long story, but CountedDrainEvent is bugging me (again)... it's not an event (it never gets scheduled; it's just a callback) and it derives unnecessarily from SimLoopExitEvent (it just uses the inherited cause and code fields to set the cause and code fields of a new SimLoopExitEvent it creates when it's really ready to exit). The resulting code is very confusing since it's not what it appears to be.
One solution would be to make it a Callback object instead of an Event; this would at least make the code match the usage and purpose. However, that's not totally trivial, since the current event is exposed through swig to python so that the count value can be set from the python code. The result is that that simple change requires more swig and python tweaking than you might expect. I'm wondering why we need to dynamically allocate this object at all... the only benefit I see is that in theory, we could have multiple disjoint parts of the system draining concurrently but with independent completion detection. In reality, I don't see how we would really do that, unless we had multiple python threads calling the python drain() function concurrently, which doesn't seem likely to happen in our lifetimes. Is anyone opposed to just using a global variable for the drain counter, and a global function to decrement it and exit the sim loop when it hits zero? Steve
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
