I've started to summarize this thread in a GREP PR: https://github.com/gnuradio/greps/pull/16
On Sun, Jan 6, 2019 at 1:58 PM Martin Braun <martin.br...@ettus.com> wrote: > 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 :) > > > Cheers, > Martin > > On Fri, Dec 28, 2018 at 4:49 PM Michael Dickens <michael.dick...@ettus.com> > 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. >> >> Jared. >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
