[Ns-developers] log time -> log context
Tom Henderson
tomh at tomh.org
Fri May 23 09:48:03 PDT 2008
Mathieu Lacage wrote:
> On Wed, 2008-05-21 at 19:35 +0100, Gustavo Carneiro wrote:
>
>> I don't know what else to explain:
>>
>> /**
>> * Set the current node that is being simulated.
>> * \warning this method has no effect on optimized NS-3 builds, as
>> it is used only for logging.
>> * \param node id of the current node, or -1 if none or not known
>> */
>> static void SetCurrentNode (int32_t node);
>>
>>
>> It's dead simple. What might be missing perhaps is some guideline
>> explaining when the user is expected to call it. Is that what you
>> mean?
>
> What is "the current node" ? What is its relationship with the "nodeid
> context" embedded in each event ? How does each event get a "nodeid
> context" ? Where does it get it from ?
>
> There are many types of "current node id". There is the one which is
> used to associate a "current node id" to the event scheduled with
> Simulator::Schedule. There is the one which is coming from the "current
> node id" of the event we are currently executing. There is the "current
> node id" used for logging. Explaining clearly the relationship between
> all these different types of "current node id" makes my brain hurt.
>
>> Using raw sockets outside of the context of an Application
>> Start
>> function makes little sense and is clearly not the way the
>> system was
>> designed to be used: yes, it can be made to work, yes, we have
>> examples
>> which do this, yes you like being able to do it but, as
>> discussed a
>> while ago in a bug report, _this is not the way the system was
>> designed
>> to be used_. If, when you do this, you do not get the best
>> logging
>> messages in the world without some extra work, such is life.
>>
>> About the extra work:
>>
>> 1. I am not convinced the extra work will be worth anything. It
>> doesn't improve readability in my opinion;
>
> It does not improve code readability. It makes the conceptual model of
> the API much more clear and defines precisely and uniquely what the
> "current node id" means by uniquely associating a single "current node
> id" to each event.
>
> What you are trying to suggest also goes against the design of the
> current API which is to move _all_ per-event arguments to the Schedule
> calls: we could have done what you suggested for all other arguments:
>
> Simulator::SetNextDelay (Time delay);
> Simulator::SetNextArguments (...);
>
> Whether or not the above is better than what we have now is not
> something I will argue about. What I will argue about is consistency of
> the design: we are not using this style of API in this header _now_ so,
> we should not use this style for new API in this header.
>
>> 2. Adding extra Schedule calls will increasing the number of events
>> and decrease NS-3 performance. I want the logging improvements to be
>> as little intrusive as possible, as all logging should be.
>
> You are worried about minimizing the number of changes to the codebase.
> I am worried about making the API understandable and consistent.
>
> Mathieu
>
>
What about asking each file to define an optional context that is
meaningful to it, and leave it out where it doesn't make sense?
e.g.
in ipv4-l3-protocol.cc
NS_LOG_COMPONENT_DEFINE ("Ipv4L3Protocol");
#define APPEND_CONTEXT \
if (m_node) \
{ \
std::clog << m_node->GetId () << " "; \
} \
then in log.h
#define NS_LOG_FUNCTION_NOARGS() \
do \
{ \
if (g_log.IsEnabled (ns3::LOG_FUNCTION)) \
{ \
APPEND_TIME_PREFIX; \
APPEND_CONTEXT; \
std::clog << g_log.Name () << ":" \
<< __FUNCTION__ << "()" << std::endl; \
} \
} \
while (false)
More information about the Ns-developers
mailing list