[Ns-bugs] [Bug 631] RealtimeSimulatorImpl not compatible with python bindings

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=631





--- Comment #12 from Mathieu Lacage <mathieu.lacage at sophia.inria.fr>  2009-07-13 15:29:39 EDT ---
(In reply to comment #11)
> I agree with Gustavo in that there a simple case that we should make very
> simple to use.  Using the default simulator implementation and calling in to

Writing a GUI is not what I could call a "simple case". The common case is
writing a simulation script, not an interactive simulation GUI. I think that it
is very reasonable to ask a GUI developer to use a special API which is not
_the most simple API_ to use but which is still ok. A callback seems really
very reasonable, unless, of course, someone can point out a fundamental flaw
with that idea.

> run one event seems to be a nice approach -- it seems to be to be such a nice
> mechanism for GUIs that I think we should resist taking it away.  I agree with
> Mathieu wholeheartedly in that RunOneEvent just isn't reasonable for anthing
> but the simplest case, though.  There are alternatives like scheduling periodic
> callbacks, but then you immediately run into complication either at the low
> level since you lose control for arbitrary lengths of time, or at hgih level
> since the callback comes back in the context of the calling thread. 

Potentially failing to work in some cases where the user has abused the
monitoring callback seems much less problematic than having ::RunOneEvent not
work at all.

[IsBlah ()]

> I hope we don't start adding similar things to Simulator.  I originally wanted

*shudder*. I feel confident: "over my dead body" :)

> to give QueryObject powers to the simulator to resolve some of this kind of
> issue.  A similar thing came up in the context of getting the actual underlying
> real time clock and scheduling real time events.  A compromise was reached and
> we gave clients the ability to get and cast a pointer to the underlying
> implementation.  You can see this in the (not very robust code from) emu
> device,
> 
>   DynamicCast<RealtimeSimulatorImpl> (
>     Simulator::GetImplementation ())->ScheduleRealtimeNow (
>       MakeEvent (&EmuNetDevice::ForwardUp, this, buf, len));

Simulator::Schedule* needs to be thread-safe to get rid of this, I think, right
?. i.e., we need to profile whether the cost of taking a lock in each method of
DefaultSimulatorImpl and making EventImpl::Ref/Unref threadsafe is not a
performance problem (I have local patches for the latter). If not, then, we
should kill this ugly code (which I am responsible for, I know).

> One way to deal with this problem is to QueryObject for a single event
> "Interface" and use it if you need it.  The default simulator implementation
> could aggregate an interface for single stepping the simulation, while the more
> complex implementations could decide based on their own issues whether or not
> to provide it.  

[capabilities]

> > But if you think about it, this is quite similar to a QI but lacks the
> clean-ness of the interface separation.

I have a very hard time understanding how this is any different from using
Simulator::GetImplementation ()->GetObject<MyCapability> () which I could live
with but which, really, I would like to avoid.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.