[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] [GREP] Remove log4cpp

From: Martin Braun
Subject: Re: [Discuss-gnuradio] [GREP] Remove log4cpp
Date: Sun, 6 Jan 2019 13:58:48 -0800

Hi all,

there's been a little discussion outside of this thread, and I'd like to consolidate all the points. Marcus, I and some others have also discussed some things on chat, too, and of course there's Jared's and Michael's comments here. Let me summarize:

- We would like to drop any kind of dependency and hand-roll our logger. I'll make some points on why further down.
- Any log message must have a severity and a "category" (or "source ID"). We already have this, but want to keep it.
  - The source ID for a block should be its ID. I like Jared's suggestion of the log-hierarchy following the block-hierarchy.
- We'll also drop the debug logger vs the regular logger. Devs can use the DEBUG and TRACE log levels for their debugging.
- We absolutely want to make sure that log messages are properly interleaved. This requires some amount of serialization/thread handling, I'll also comment on that later.
- By default, there should be log files and logging to stderr. However, we also want to enable (or at least, not disable) other logging paths, such as journald, or network logging. This might be as simple as providing generic hooks for other loggers.
- If  possible, we would also like to pull in log messages from dependencies, so they all go through the same logging interface. For example, UHD log messages could be redirected to the GNU Radio logger when running gr-uhd applications, so UHD and GNU Radio don't clobber each other with different formats of their logging messages.

Out of these requirements, there fall some design decisions:
- There will be one central "root logger". All other logger objects (such as a logger attached to a block) will be childs of the root logger
- Every child logger can filter log messages by severity. Do we also want to filter in the root logger, or do we just inherit the default log level from it? That's up for debate.
- The root logger will implement a thread-safe multi-writer queue for log infos. It will serially handle the actual logging, which means the logging is not fully synchronous -- but it also means that the publishing of the log messages is not handled by the thread that is producing it, which is good for performance.
  - We will most likely start with the dumbest form of such a queue, maybe a std::queue with a mutex and a notification variable. We can optimize later, if need be. Lockfree data structures tend to be worse for best-case and better for worst-case latency, which probably makes them less suitable but who knows.
- The root logger will be created at runtime in a singleton pattern. Andrej pointed out that might cause trouble at destruction time, so we should think about that. Maybe only child loggers share a reference to the root logger, and the singleton factory only stores a weak pointer to it. It runs a separate thread to dispatch log messages to the various logging back-ends.

On top of that, here's a couple of suggestions from myself, which are the least fixed out of all of these bullet points:
- We could further simplify the block logging interface by adding an API call to the block itself, rather than exposing the logger object. This guarantees that the source ID for block log messages is always correct.
- I want (optional) colours on the stderr output :)


On Fri, Dec 28, 2018 at 4:49 PM Michael Dickens <address@hidden> wrote:
I'll second what Jared wrote, and add the following: I'd like -any- logging GR uses to provide protected printing, such that logged messages do not interleave. [Obviously, unlogged messages might interleave / intermix; all depends on the actual printing interface.] Trying to parse such interleaved messages is a total PITA. I've personally gone so far as to implement a mutex interface via SWIG from C++ to Python, to allow logged messages in both to not interleave. Ideally, all of stdout and stderr would be redirected to the logging interface, regardless of language source. Log4Cpp provides the printing blocking (non-interleaving) functionality, though it doesn't coerce both C++ and Python into the same printing interface (at least in my testing). - MLD

On Fri, Dec 28, 2018, at 7:08 PM, U L wrote:
I think many users, myself included, use logs for debugging.  I would hesitate to have the log messages propagate through the very system that you are trying to debug with said messages.  I would rather the logs be emitted from the system under test as simply and promptly as possible.  I think that hierarchical organization within the logs should be handled by log metadata.  It's not clear that one would want to impose the same naming hierarchy on logs as you do your flowgraph, but one could do so if desired.


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]