[Ns-developers] trace side-effects (Was: datagram socket tx buffer back pressure)

[Mathieu Lacage]

On Mon, 2010-03-29 at 10:59 +0100, Gustavo Carneiro wrote:
> On Tue, Mar 23, 2010 at 4:00 PM, Mathieu Lacage
> <mathieu.lacage at sophia.inria.fr> wrote:
> [...]
>         c. use existing trace sources/sinks in NetDevice. This sucks
>         because, by
>         definition, traces are not supposed to have any side-effect
>         other than
>         maybe generate some logging.
> 
> 
> Just a small aside from the main topic.
> 
> 
> Not saying we should use traces here, but that statement worries me.
> I proposed in the past we should add the concept of "signal" to ns-3,
> to which you argued that traces an fulfill the same role, and I did

I don't think I ever said that they did the same thing (but, hey, my
memory could be wrong). your signals clearly had been designed to have
side-effects and they could return a value. Traces can't and they don't
return a value. I probably said that I did not see any obvious immediate
use for them (signals) at the time but if we identified a couple of
potential users in our codebase, I would be fine with using your
signals.

>  agree with you.  Now you are saying traces cannot have side-effects.
> Well, in my code I have been using a lot trace callbacks with serious
> side-effects (e.g. searching for a new AP when the wifi signal is
> lost).  So, make up your mind already about the role of tracing...

I think that it's ok from a user perspective but model code should not
use sinks with side-effects. i.e., if you hack this in your scripts,
it's fine because you control everything and you know what you are doing
but we should not do this in ns-3's main ip stack because, then, users
would have to know about these side-effects and it would be hard to
impossible to figure out the interaction between these side-effects.

Mathieu