|
Boost : |
From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-05-04 16:12:42
On 5/4/05, Rob Stewart <stewart_at_[hidden]> wrote:
> From: Caleb Epstein <caleb.epstein_at_[hidden]>
> >
> > If one uses the supplied write_to_file appender, the messages will be
> > written to the output file as soon as they are complete. So for
> > example,
> >
> > BOOST_LOG(debug) << "Wrote " << len << " bytes to socket fd " << fd;
> >
> > would write a single message like "Wrote 56 bytes to socket 3" or
> > nothing at all (e.g. if the application crashed sometime in the middle
> > of formatting the message). I think this is eminently reasonable and
> > hardly "useless".
>
> The point is not so clear if the expression following BOOST_LOG()
> includes side effects that cause the application to crash, for
> example.
>
> If the stream provided by BOOST_LOG() were unbuffered, then
> output would be flushed as soon as it was formatted, so you'd get
> output up until the point of the crash. Any buffering means that
> the buffered output is lost when the app crashes.
Without some sort of buffer between message formatting and message
output, how do you allow multiple threads to write to a log without
intermingling their messages? Locking on every op<< isn't good
enough. Are you really that concerned about losing a single log
message in a crash scenario? Perhaps if its something like "The
reason I'm crashing is " << e.what() :-)
Bear in mind:
* If you are really concerned that the operations you're invoking are
fragile, you can split them across multiple calls to BOOST_LOG
* John has agreed to add exception guards to the logging macro(s).
Perhaps something like the Boost.Test execution monitor that catches
SIGSEGV etc could be optionally put in place as well.
* Not that this is a ringing endorsement, but you'd do no better with
printf ("The operation-which-might crash returned: %d\n", crashme());
I really think that some level of buffering is unavoidable.
-- Caleb Epstein caleb dot epstein at gmail dot com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk