Re: The usefulness of application logging
Hendrik Schober wrote:
kanze <kanze@gabi-soft.fr> wrote:
Hendrik Schober wrote:
kanze <kanze@gabi-soft.fr> wrote:
[...]
I've still not found a good solution for this when there is a
requirement to be able to change the configuration on the fly in
a multithreaded environment. [...]
Ahh. No MT here yet. But this is an upcoming requirement,
so I have to deal with this sooner or later. The fact
that locking is required does give me a headache and I
have been thinking a lot about how to minimize that -- so
far to no avail.
There are two distinct issues with respect to threading. If
the logging is configured once at start-up (before threading
starts), then you can read the configuration variables without
locking, and it is relatively simple to only lock when actually
generating a log message. Given that generating a log message
will almost certainly involve a certain number of allocations
and some physical output, the extra lock seems acceptable. The
problem occurs if you want to be able to reconfigure the log
dynamically, while the threads are running, because then, you
have to somehow synchronize all accesses to the configuration
variables. And you certainly don't want a lock in your test
whether a particular level is active or not.
Is this library available somewhere on the network. [...]
No it's not. Somone whose opinion I value high already
tried to make me write an article about it and publish
the code, but I so far haven't got around doing it... :(
I understand the problem. All too well, in fact.
In my own case, I've finally resorted to just making the
code and what documentation I've had the chance to write
available (at http://kanze.james.neuf.fr, at least for the
moment), as is,
Where? I quickly looked around, but haven't found the
logging stuff.
Sorry. I was talking in general. All of the actual logging
systems I've done have involved proprietary code, so I can't
make them available per se. Some of the classes I've used in
them, however, are there: OutputStreamWrapper and
EventGeneratingOutputStream. Generally, I'll have a table of
ostream* somewhere, with a pointer to an appropriate ostream if
tracing is active for that level, and a null pointer otherwise.
(The appropriate ostream points to a filtering output streambuf
which keeps track of whether we're at the start of line or not,
and forwards to an output streambuf which forwards to whatever
the final targets are---there may be more than one---, a
filebuf, a streambuf which writes to syslog, or a streambuf
which collects the data and sends it as an email on flush.)
Logging itself is typically invoked by means of a macro along
the lines of:
#define LOG( level ) logTable[level] != NULL
&& logStream( level, __FILE__, __LINE__ )
logStream is a function which returns an OutputStreamWrapper
whose lifetime "knows" about the first level filtering
streambuf, and collaborates with it:
-- it passes it the line header---the filtering streambuf
outputs the line header at the start of each line, and
replaces it with indentation for the following lines.
-- it calls flush on it on final destruction---if the filtering
streambuf is not at the start of a line, it outputs a '\n'
before forwarding the flush on.
In a multithreaded envirionment, it is also the
OutputStreamWrapper lifetime handler which acquires and releases
the lock.
[...]
We compile out /some/ of it. Let me explain:
The lib allows to specify different targets for logging.
Currently, there is "debugger" (what developers want to
see during debugging), "logger" (giving an idea what the
app is currently doing), and "user" (what should be shown
the user). Also, there is several severities ("debug",
"log", "info", "warn", "error", "fatal"). Targets and
severities can be freely combined for each log message.
(Both are passed as template parameters to allow compile-
time evaluation).
That's an interesting comment. I usually use macros for
logging, in order to be able to automatically insert __FILE__
and __LINE__. Since I'm already using macros, I've not been
very motivated to consider templating it. (Also, of course,
much of it was developped before I had very good template
support.)
Logging is done through loggers, each of which forwards
log messages to another one. There is a global logger
singleton at the root of the resulting DAG. Each logger
defines which targets/severities it will let pass and
which it will discard. (This forwarding effectively is
a compile-time operation.) If a message makes it to the
singleton it will be discarded unless there's a listener
registered for its target and severity. (The test is the
above mentioned 'if'.)
I'm not sure that I understand the role of the intermediate
loggers. Unless...
On one very large project, I did have a "configuration" table
per sub-system. So that you could configure debug for a single
subsystem, without getting swamped with messages you weren't
interested in. (I also defined a couple of "virtual" subsystems,
which represented things like e.g. messages on a socket.)
Listeners are can be registered (and unregistered) with
the singleton. They consist of a formatting layer (which
is controlled through policies) and some writer that
finally writes the messages somewhere.
Typically a release build would have target "debugger"
and severity "debug" compiled out. Everything else is
left in the code.
Left in the code, but activated by means of a configuration
file, I suppose.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]