Bugzilla – Bug 492
It would be useful to have a pre-simulate state (and post)
Last modified: 2009-11-24 06:17:30 EDT
You need to log in before you can comment on or make changes to this bug.
I have run across several situations where it would be very useful to have a simulation state that happens before the simulator actually starts executing events. For example, in the emu and tap devices, it is desirable to wait until the simulation is fully configured before creating and configuring the emu or tap device. If you schedule this work for 0 seconds, you can spend quite a bit of time doing this work that is really not part of the simulation as the first events. This isn't really a problem unless you start thinking in terms of real-time. Then the first events could consume large amounts of real-time unexpectedly and if you have a "hard" real-time constraint, you could lose the catch-up game before you even start. We have a separate class of events driven by, Simulator::ScheduleDestroy (blah ...) that are run after the simulator is done with its "normal" events. It would be very useful to have another class of events driven by, Simulator::ScheduleBefore (blah ...) that would be run before the simulator got started. I'm a fan of symmetry so I think it would be nice to have a symmetrical method Simulator::ScheduleAfter (blah ...) that you would use to "undo" what you did in ScheduleBefore. It also seems nice to have these events called automagically for you. Perhaps a function Simulator::Exectute () { Simulator::Before (); Simulator::Run (); Simulator::After (); Simulator::Destroy (); }
The problem with what you describe is that it relies on the user to call Before and After himself so, if we prescribe that these methods must be called, we make all existing scripts invalid. Thus, I have to ask: why can't the user call directly the emu/tap initialization functions at the proper time ? Another option would be to make ::Run call PreRun and PostRun but I am not sure how that would fit with the use of Run+Stop+Run+Stop, etc. To summarize, I don't see any obvious winning solution.
(thinking out loud). It might be that this problem is really the responsability of another layer, on top of Simulator.
> Thus, I have to ask: why can't the user call directly the > emu/tap initialization functions at the proper time ? The user *can* be asked to know that s/he has got to call a certain method at a certain time. We would have to communicate to the user via documentation what that method is and when it should be called; and rely on the user to do it correctly. This introduces an annoying new requirement that is extremely position dependent in a script. I don't think this is good. I think it is better to *not* export that requirement since the device knows when it needs to be called, how it needs to be called, and knows when it has all of the information it needs. Currently it schedules an event to do it. It works well. The user doesn't need to know anything about it. It would be nice not to have to place that burden on the user and at the same time not mess up the realtime situation at the first event time. What I suggest would mean calling a generic function just before Simulator::Run. Compare this with having to understand, for example, if you want to add a tap device you have to call function X with parameters Y and Z just before run; if you want to add an emu device you have to call function X' with parameters a, b, and c; if you want to run some other model, you have to call blah, blah, blah. IMO, It's a good thing for several reasons
> (thinking out loud). It might be that this problem is really > the responsability of another layer, on top of Simulator. That could be certainly be the case. It seems to duplicate some functionality given the existence of Simulator::Destroy. Unless you want to break out Simulator::Destroy into this new layer.