NFD » ndn-cxx

Some work is done during Mar 2016 hackathon, and these code can be reused.

https://github.com/2nd-ndn-hackathon/ndn-cxx-logging

When logging is disabled, overhead should be low.

Let me elaborate. When logging is disabled at compile time, the overhead should be zero (easy to do with macros). When logging is disabled at run time for a specific component, the overhead should be minimal (substantially harder to do, esp if logging must be thread-safe).

20160621 NFD call talked about the plan on bringing this into ndn-cxx master branch.

@Davide, since you are familiar with this feature and the underlying libraries, can this be assigned to you?

Junxiao Shi wrote:

@Davide, since you are familiar with this feature and the underlying libraries, can this be assigned to you?

It depends... consider that I won't have time to work on it at least until October.

I think the logging subsystem should be made somewhat configurable. I can think of two major things right now:

• synchronous vs asynchronous sink frontend
• enable/disable auto_flush in the sink backend (performance vs reliability tradeoff)

I agree with note-10 but they should be in separate issues for the future.

do we want to always (unconditionaly) build the generic logging facility (for 3rd party apps use), but make internal ndn-cxx logging switchable at build-time (to avoid all kind of overhead)?

I think the eventually answer should be YES. But currently it's disabled altogether, because the logging facility is not yet ready for use externally.

For example:
Imagine NFD logging is replaced by logging facility, and both ndn-cxx and NFD declare a logger named Face.
It would be unclear whether the configuration "Face=DEBUG" wants to enable ndn::Face logging or nfd::Face logging.
This and other similar problems should be solved in separate issues, before the logging facility is built by default and exposed for external use.

Currently, logging macros are named NDN_CXX_LOG_*. I wonder whether CXX is necessary.

So far, #include guards start with NDN_ rather than NDN_CXX_. NDN_LOG_* would make code calling logger functions shorter.

Junxiao Shi wrote:

Currently, logging macros are named NDN_CXX_LOG_*. I wonder whether CXX is necessary.

So far, #include guards start with NDN_ rather than NDN_CXX_. NDN_LOG_* would make code calling logger functions shorter.

+1

Junxiao Shi wrote:

I think the eventually answer should be YES. But currently it's disabled altogether, because the logging facility is not yet ready for use externally.

I assumed it was public API...

Imagine NFD logging is replaced by logging facility, and both ndn-cxx and NFD declare a logger named Face.
It would be unclear whether the configuration "Face=DEBUG" wants to enable ndn::Face logging or nfd::Face logging.

I don't see the problem... NFD and ndn-cxx should use different env variables.

This and other similar problems should be solved in separate issues, before the logging facility is built by default and exposed for external use.

Fine with me but let's open a ticket, code duplication between NFD and ndn-cxx isn't a good thing.

Junxiao Shi wrote:

The overhead of logging macros should be no more than a comparison when logging is not enabled.

Fully agree.

In 2918,15 code, default severity level is INFO, so any messages at or above this level is generated and written to a null stream, which violates this requirement.

I need to change the initial severity level to NONE, but set the default level to INFO the first time when Logging::setDestination is invoked, or severity levels are set through Logging::setLevel or environ.

And then what do you do if the app calls setDestination(nullptr) after a while? Do you set the levels back to NONE? What if the level of some modules were individually changed by the app?

Finally, some testing is needed to ensure application can still compile and operate with logging facility compiled in but not enabled.

I cannot parse this sentence.

Answer to note-20:

The "NONE" optimization is applied only before the first setDestination call. If destination is set OR severity levels are set (thru function call or environ), "NONE" optimization won't be applied again.

Junxiao Shi wrote:

The "NONE" optimization is applied only before the first setDestination call. If destination is set OR severity levels are set (thru function call or environ), "NONE" optimization won't be applied again.

hmmm I don't know... I don't like it too much... it's somewhat inconsistent/asymmetric behavior. What would be the downside of simply defaulting all log modules to NONE (the additional function call for the app is not a big deal in my opinion)? Or at this point we could have a default destination of std::clog/cerr, if modules default to NONE...

I agree with note-22 to set default severity at NONE and default destination to std::clog.