[boost] Re: Logging Library -- Formal Review Request

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-05-04 22:57:50

Gennadiy Rozental <gennadiy.rozental <at> thomson.com> writes:
> I have several questions about this:
> 
> 1. How do you know in general which log present trace of first invocation, 
> and which one second:
> 
> void acess_db( ... ) {
>     if( some error )
>        log << "invalid account key" << key;
> }
> 
> int get_balance(...){
>     ...
>    if( !access_db(...)  )
>        return 0;
> }
> 
> ...
> 
> log << "Mary has balance: " << get_balance() << " and John has balance: " << 
> get_balance()
> 
> Let say an output is:
> 
> > access_db
> Invalid account key: 25
> < access_db
> > access_db
> < access_db
> Mary has balance: 0 and John has balance: 100
> 
> -----------------------------------------
> 
> Could you say where an error occurred (without looking into code and 
> knowledge how log system is working)?

No, I can't. But then there is an awful lot of stuff in detailed logs that
falls into the same category, with or without reordering.

> 
> Would it be like this:
> 
> Mary has balance:
> > access_db
> Invalid account key: 25
> < access_db
> 0 and John has balance:
> > access_db
> < access_db
> 100
> 
> It would be clear.

Yes. However, I have thought of

LOG(x) << "foo" << a() << b();

as a request to build then log a message, not as a reqest to write to a log
stream. All the logging systems I'm familiar with have the same concept (eg
syslog, windows nt event log).

> I understand that later is slightly less readable but In my experience 
> usually what happened is that log entry fragmenting occur only on hi levels 
> of log (or in case of error). While with regular log level and normal log 
> flow it's not an issue.

Ok.

The only think I can think of that preserves the log message concept while
giving the stream view that you want is to record some sort of nesting level
and either cache to give something like the following directly, or just include
a level tag used by a viewer to format as:

Mary has balance: 0 and John has balance: 100
  > access_db
  Invalid account key: 25
  < access_db
  > access_db
  < access_db
Next log message is back here

I'm not sure if that is close enough?

> 
> 2. How does the log system know when to dump the cash? Does it introduce any 
> scope guards?

Do you mean the cache used on startup or the buffering used to build a log
message? I'll try to answer both - pick the applicable one... The cache is only
used to avoid missing log info from static c'tors etc. that may run before the
logging system itself has been configured (logs connected to appenders). Once
the logging is initialized, the cache is not used. The buffer is only used to
build a single message. Its scope is the single LOG(x) << ...; expression.

> 
> 3. How deep it will work? And how many different cashed we could have the 
> same time?

The cache is limited to prevent excessive memory use if the user forgets to
configure the log. The buffer to build a message is used to build a single
message.

> 
> 4. What kind of overhead it introduces? Now instead of directly writing into 
> stream we keep second copy of every piece of log essentially doubling the 
> memory usage and increasing log overhead, isn't it?

I'm too confused about what you were asking above to answer this, sorry.

> 
> > Looks in order to me. I'm still not sure what the alternative is?
> 
> It may be desirable in some circumstances. But it may be not. IMO Log should 
> follow program flow 1:1. Including order of events during log entry output.

But then it isn't just a log, it's the whole tree ;-)

I do see your point now though. I just can't quite see how to fit it into an
event logging system. The above thoughts about tracing actual program flow
also fail to consider how to reconcile this with the idea of multiple logs and
appenders. In general you can have an L x A connection matrix of logs and
appenders. It is quite likely I'd write my access_db messages to
the db_log, and my account_balance etc messages to the acct_log. These 2 logs
may or may not both be connected to the same (set of) appenders. I guess the
merging/reordering could only work when the writes were to the same log.

Darryl.