-
Notifications
You must be signed in to change notification settings - Fork 3
The Issues
{{toc}}
There most likely should be. Should single line message (without an “end of message” indication) be allowed?
Some libraries write “log messages” (error, warning, etc.) to cerr. To
have these message and
mf message go to the same destination, we could configure message
facility to use cout/cerr and
then redirect those streams to a file. Note: unix allows the process to
redirect it’s own streams.
Writing messages to log files — at some rate there will eventually be
back pressure.
Messages can be dropped to postpone or eliminate the backpressure.
Should that be viewed as an indication that the application is
logging (to files) too many messages and that the logging needs to be
adjusted?
One message destination may not be appropriate. Many people may not
think that there
is more than one or they might only ever want to look in one place. When
debugging, it
may happen that an excessively large volume of message are written to a
log file, which
in addition to creating large unwieldy files, can adversely effect
performance. These issues
are mitigated by directing debug logging to a circular memory buffer.
How important is the mf’s message rate limiting feature?
One file with messages from multiple nodes.
What time resolution is needed? Seconds? Milliseconds? Microseconds?
If microseconds are needed, how likely would it be to need CPU and
thread (tid) information?
There are many details which are not needed when all is well. When there
are problems, should the
messaging be able to show interactions with other programs and/or the
OS? Should the details be selectable?
Without recompiling?
“Success/Info” logging should go to an obvious location. If a system
issue comes up and more info (logging)
needs to be added, should newly added log messages (“debug information”)
be directed to the “Success/Info” (obvious) location?
If TLOG_{DEBUG,TRACE,ARB) messages are added, these message and be
run-time/dynamically directed to the “Success/Info” location.
In a relative sense, computers are good at binary calculations and data
movement and they are not
as good at converting numbers (especially floating point)