[Ns-bugs] [Bug 492] New: It would be useful to have a pre-simulate state (and post)
code@nsnam.ece.gatech.edu
code at nsnam.ece.gatech.edu
Thu Feb 5 10:09:09 PST 2009
http://www.nsnam.org/bugzilla/show_bug.cgi?id=492
Summary: It would be useful to have a pre-simulate state (and
post)
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: craigdo at ee.washington.edu
Estimated Hours: 0.0
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 ();
}
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Ns-bugs
mailing list