(In reply to comment #0)
> Currently, when you use Simulator::Stop(), the simulator time is not updated at
> the end of the simulation.  It remains at the time of the last event to be
> processed.  For example, the following will print "0ns":
> 
>   Simulator::Stop(Seconds(4));
>   Simulator::Run();
>   std::cout << Simulator::Now() << std::endl;
> 
> This is non-intuitive, and a potential annoyance for some add-on modules which
> do not necessarily know when the simulation script set the simulation to end. 
> Example tasks affected by this include calculating partial traffic, updating
> final positions, etc.  A potential workaround is the following, which will
> print the expected "4ns":
> 
>   Simulator::Schedule(Seconds(4), &Simulator::Stop);
>   Simulator::Run();
>   std::cout << Simulator::Now() << std::endl;
> 
> But, this has the important downside of allowing some events scheduled at the
> same time to be executed before this event is processed.
> 
> I believe the fix is as simple as setting m_currentTs to m_stopAt when the
> simulation ends because m_stopAt > NextTs(), but am not 100% convinced.

While the proposed change seems fairly intuitive, I am worried about potential
breakage in the case where you call Simulator::Run multiple times.

I have to ask, though, why does't Simulator::Stop (delay) not just schedule an
event to call Stop at the right time ? That would be even simpler and would
solve this problem.

Patch attached.

> 
> Thx
> 

Created an attachment (id=330) [details]
get rid of m_stopAt

(In reply to comment #2)
> Created an attachment (id=330) [details] [details]
> get rid of m_stopAt
> 

So, to summarize, this patch passes all tests and regressions. I also believe
that it gets rid of the unused m_stopAt variable in the realtime scheduler
(that variable was read but never set to anything but zero) and results in a
final code decrease.

Seems like low risk and fairly ok. assigning to craig to decide whether to
apply or not.