> I think the right solution is > that for each of these we should either change it into the first model or > eliminate the bypass option altogether and always do a separately scheduled > callback. > > I think the distinction of having main() call y() directly rather than > x_cb() is potentially important, as this gives you points where you can do > slightly different things depending on whether you did the event or bypassed > it. It also (to me) provides some logical separation between "what comes > next" (the code in y()) and how you got there. I'll agree with these points. It's what I was trying to say in my "draft" email but was not sure if I had the problem all the way down correctly.
If you follow this convention somehow throughout the code, then the callback problem gets erased as we have the ability to bypass and schedule events without implicitly stacking events from one function call. I was trying to think of a way that we could enforce that as a sanity check, but couldnt come up with anything good. The only thing I could think of mark the type of event in a derived Event class, then when a event get scheduled check to see if 2 dependent events are being scheduled. However, that doesnt really solve the problem so I was stuck a bit there. The best solution might just to be check the code and change it appropriately. -- =========== Korey L Sewell PhD Candidate Computer Science & Engineering University of Michigan _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
