Bugzilla – Bug 752
Object::DoStart is not executed for objects created at t > 0
Last modified: 2010-01-08 12:05:07 EST
It is observed, that only objects created before Simulator::Run() are initialized via DoStart (). Attached program illustrates this. Expected output is A::A() A::DoStart() and actual is just A::A(). In particular I see no way to create and start applications dynamically at t > 0 since application start is implemented via Application::DoStart(). If Object's behavior is believed to be correct, I ask for particular Application fix (probably revert DoStart -> Start and schedule it from SetStartTime()).
Created attachment 678 [details] example program
(In reply to comment #0) > It is observed, that only objects created before Simulator::Run() are > initialized via DoStart (). Attached program illustrates this. Expected output > is > > A::A() > A::DoStart() > > and actual is just A::A(). > > In particular I see no way to create and start applications dynamically at t > > 0 since application start is implemented via Application::DoStart(). > > If Object's behavior is believed to be correct, I ask for particular > Application fix (probably revert DoStart -> Start and schedule it from > SetStartTime()). I do not believe we ever explicitely supported the dynamic creation of applications during simulation, just like we don't support dynamically creating devices during simulation so, it is no wonder that it does not work. I think that the first issue is deciding whether we want to support creating applications during the simulation. CCing tom since he will have input on that.
> I do not believe we ever explicitely supported the dynamic creation of > applications during simulation, I use this since my first days with ns-3 and it always worked. Old Application::Start and Stop logic was very simple -- just schedule DoStart and DoStop, this can be done at any time.
(In reply to comment #3) > > I do not believe we ever explicitely supported the dynamic creation of > > applications during simulation, > > I use this since my first days with ns-3 and it always worked. Old > Application::Start and Stop logic was very simple -- just schedule DoStart and > DoStop, this can be done at any time. That was accidental: we never designed the system to support this and I introduced the Start method without this feature in mind.
> That was accidental: we never designed the system to support this and I > introduced the Start method without this feature in mind. Well, if you have serious doubts that ns-3 can support on demand application start and stop, I will implement any simple workaround in my applications. But I wonder why -- do you worry about ported "real" applications?
(In reply to comment #5) > > That was accidental: we never designed the system to support this and I > > introduced the Start method without this feature in mind. > > Well, if you have serious doubts that ns-3 can support on demand application > start and stop, I will implement any simple workaround in my applications. But > I wonder why -- do you worry about ported "real" applications? I never said that this could not be supported. I merely said that, so far, we never actually purposedly made this work and if we want to make this work again, we need to think carefully about the consequences. So, I have nothing against it. I am merely saying that we need to think this through. i.e., it's not a 10s patch.
(In reply to comment #2) (In reply to comment #2) > (In reply to comment #0) > > It is observed, that only objects created before Simulator::Run() are > > initialized via DoStart (). Attached program illustrates this. Expected output > > is > > > > A::A() > > A::DoStart() > > > > and actual is just A::A(). > > > > In particular I see no way to create and start applications dynamically at t > > > 0 since application start is implemented via Application::DoStart(). > > > > If Object's behavior is believed to be correct, I ask for particular > > Application fix (probably revert DoStart -> Start and schedule it from > > SetStartTime()). > > I do not believe we ever explicitely supported the dynamic creation of > applications during simulation, just like we don't support dynamically creating > devices during simulation so, it is no wonder that it does not work. I don't think we ever explicitly excluded it, however, and there are statements in our documentation such as "ns-3 is a C++ based system, except we have some special base classes..." so I think it is probably going to be surprising to users to discover that some Objects can't be instantiated after time 0. > > I think that the first issue is deciding whether we want to support creating > applications during the simulation. CCing tom since he will have input on that. What would it take to support it?
(In reply to comment #7) > > I do not believe we ever explicitely supported the dynamic creation of > > applications during simulation, just like we don't support dynamically creating > > devices during simulation so, it is no wonder that it does not work. > > I don't think we ever explicitly excluded it, however, and there are statements > in our documentation such as "ns-3 is a C++ based system, except we have some > special base classes..." so I think it is probably going to be surprising to > users to discover that some Objects can't be instantiated after time 0. It's already the case (not legal to create them after time 0) for NetDevice, Channel, and Node and I thought that it was the case for Application: all these objects make up the overall simulation topology for me and I always expected them to be fully static/constructed before simulation starts. I understand that it's reasonable and convenient to create applications dynamically but I never thought that this would be allowed. > > I think that the first issue is deciding whether we want to support creating > > applications during the simulation. CCing tom since he will have input on that. > > What would it take to support it? I do not really know: I do not know what the impact is going to be on the multithreaded stuff.
Created attachment 679 [details] try to support dynamic creation of applications Can you try that patch ?
(In reply to comment #9) > Created an attachment (id=679) [details] > try to support dynamic creation of applications > > Can you try that patch ? it helps, thank you. Obviously general problem with objects illustrated by attached do-start.cc program still here, only applications and devices are fixed.
(In reply to comment #10) > (In reply to comment #9) > > Created an attachment (id=679) [details] [details] > > try to support dynamic creation of applications > > > > Can you try that patch ? > > it helps, thank you. > > Obviously general problem with objects illustrated by attached do-start.cc > program still here, only applications and devices are fixed. Well, it's pretty clear that the Start/DoStart methods will not get magically invoked for you unless your objects are a part of the structure of the simulation topology. i.e., if you create objects yourself, you become responsible for calling Start yourself. Does this clarify the issue for you ?
> Well, it's pretty clear that the Start/DoStart methods will not get magically > invoked for you unless your objects are a part of the structure of the > simulation topology. i.e., if you create objects yourself, you become > responsible for calling Start yourself. That wasn't clear for me at all. When I read in CHANGES.html the description: <li><b>Object::DoStart</b>: Users who need to complete their object setup at the start of a simulation can override this virtual method, perform their adhoc setup, and then, must chain up to their parent. I was sure that CreateObject() just schedules DoStart at Seconds(0). Now I see that my conclusion was wrong since it is said "at the start of a simulation". Nevertheless, I ask you to extend that description and explicitly clarify that DoStart is not called at all for objects created after the start of a simulation. > Does this clarify the issue for you ? Yes, thank you. I propose to commit patch, update docs and close this bug.
This patch changes the timing of a couple of regression tests in suspicious ways. Need to understand before committing. < 0.000263 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] < 0.000279 Acknowledgment RA:00:00:00:00:00:07 < 0.000357 Assoc Response AID(0) :: Succesful < 0.000501 Acknowledgment RA:00:00:00:00:00:0a vs. > 0.000158 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS > 0.000396 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] > 0.000412 Acknowledgment RA:00:00:00:00:00:07 > 0.000490 Assoc Response AID(0) :: Succesful
I have verified that current ns-3-dev does not trigger regressions with this patch applied so, I pushed it. changeset: 8788d85a6c3e