Bugzilla – Bug 1000
Make RealtimeSimulatorImpl last until stop
Last modified: 2012-03-26 06:13:39 EDT
Created attachment 988 [details] Make RealtimeSimulatorImpl last indefinitely until a Stop event is processed. The RealtimeSimulatorImpl will stop immediately if no events are scheduled at the beginning of the simulation. If no events are generated inside a simulation, the RealtimeSimulatorImpl forces to define in advance how long the simulation should last by scheduling a Stop event. In some cases it could be necessary to make a realtime simulation last indefinitely waiting for external events to occur and be able to schedule the stop of the simulation after its start. I would like to propose to change the behaviour of the RealtimeSimulatorImpl to last indefinitely, even when no events have been scheduled, until a Stop event is processed. I attach a patch with the proposed change ( plus a modification on the realtime/realtime-udp-echo example to adapt it )
Be aware that if you do this, and use Control-C to end your simulation, your traces will not be written out correctly. Unless, of course, you intentionally crash your simulation to stop it. Heavy sigh.
I guess we should do this and maybe add a C-C handler to do the right thing (i.e., SIGINT I think) ?
(In reply to comment #2) > I guess we should do this and maybe add a C-C handler to do the right thing > (i.e., SIGINT I think) ? The idea behind allowing the RealtimeSimulatorImpl to run indefinitely would not be to stop the simulation using ctrl + C, but to schedule the stop event from another thread. As for the C-C handler, maybe it would be possible to schedule a stop event in the handler? Another consideration is that the Python bindings for ns-3 would ignore signals by default, when not running the default simulator implementation. So when running a realtime simulation from a Python script ctrl + C would be ignored.
(In reply to comment #3) > (In reply to comment #2) > > I guess we should do this and maybe add a C-C handler to do the right thing > > (i.e., SIGINT I think) ? > > The idea behind allowing the RealtimeSimulatorImpl to run indefinitely would > not be to stop the simulation using ctrl + C, but to schedule the stop event > from another thread. yes. > As for the C-C handler, maybe it would be possible to schedule a stop event in > the handler? yes, this would be nice. > Another consideration is that the Python bindings for ns-3 would ignore signals > by default, when not running the default simulator implementation. So when > running a realtime simulation from a Python script ctrl + C would be ignored. yes, such is life.
> > > Another consideration is that the Python bindings for ns-3 would ignore signals > > by default, when not running the default simulator implementation. So when > > running a realtime simulation from a Python script ctrl + C would be ignored. > > yes, such is life. Couldn't a python signal handler be written to call stop? IMO the proposed patch would be nicer for integration with network namespaces,
Created attachment 1194 [details] Make RealtimeSimulatorImpl last indefinitely until a Stop event is processed Updated version of previous patch for ns-3.11 (head). This version of the patch avoids busy waiting and performs m_synchronizer->Synchronize instead.
Created attachment 1195 [details] SIGINT signal Handler to flush traces when simulation is interrupted with Ctrl-C
Created attachment 1196 [details] Code used to test the SIGINT Handler patch
Created attachment 1197 [details] Signal checking from Python Bindings during simulation run This patch was provided by Claudio Freire.
About the patches: * "attachment #1195 [details]" sets a SIGINT handler that flushes trace files upon interruption by Ctrl-C. I put the change in Simulator instead of RealtimeSimulatorImpl, because the same problem of "unflushed" traces might occur for all simulator implementations. Also, after executing the signal handling code, the previous handler is restored and the signal is re-raised to continue the expected behavior (Other libraries might have overridden this behavior in the same process). For this reason I just call to "FatalImpl::FlushStreams ()" instead of invoking Simulator::Stop (). The later is not compatible with immediately re-raising the signal to restore the expected behavior. * "attachment #1197 [details]" Handles interruption during execution when the simulation is run using Python bindings, and does invoke Simulator:Stop(). To test it I run: import ns3 value = ns3.StringValue( "ns3::RealtimeSimulatorImpl") ns3.GlobalValue.Bind ("SimulatorImplementationType",value) ns3.Simulator.Run() ( Ctrl-C will stop execution )
Created attachment 1218 [details] Minor FatalImpl::FlushStreams() fix A somewhat related issue, there seems to be a small bug in FatalImpl::FlushStreams() triggered when no streams are registered.
Regarding the signal handler patch, can Simulator::RunOneEvent() be called more than once? If so, will subsequent calls to OverrideInterruptHandler() suppress any existing signal handler? Also, in InterruptHandler() it might be better to use raise (sig_num); to allow the same code to handle multiple signals (SIGTERM?).
(In reply to comment #12) > Regarding the signal handler patch, can Simulator::RunOneEvent() be > called more than once? If so, will subsequent calls to > OverrideInterruptHandler() suppress any existing signal handler? Yes. Indeed this could happen. One solution to avoid this problem could be to add a static boolean flag to mark when the handler has been overridden, so this is not done twice. This flag would be reset upon execution of the InterruptHandler. Other solution is to reset the original handler after each RunOneEvent() or Run() call, so to force restoration of the original handler after every run... but maybe this would have a high performance impact for the RunOneEvent case. What do you think? > > Also, in InterruptHandler() it might be better to use > > raise (sig_num); > > to allow the same code to handle multiple signals (SIGTERM?). Ok. (Although to consider handling multiple signals might make the seconds option above the only viable one)
(In reply to comment #11) > Created attachment 1218 [details] > Minor FatalImpl::FlushStreams() fix Nice. That patch was missed. If you want to make sure we pull in patches like that, report a separate bug next time :) > > A somewhat related issue, there seems to be a small bug in > FatalImpl::FlushStreams() triggered when no streams are registered. I think that the above patch should fix that case. Or maybe you could explain what you mean by "a small bug" ?
changeset: 3b9223ce47df