> 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. It's not that much :)
> 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? I don't think a global variable will work because if you have two systems, they may not drain at the same time. I think that a drain count on the system object could work fine though. Nate _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
