From: Rob Stewart (stewart_at_[hidden])
Date: 2005-05-05 13:24:39
From: Caleb Epstein <caleb.epstein_at_[hidden]>
> 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() :-)
I was raising a flag as to a problem scenario and suggesting that
there are multiple forces to be balanced to reach an optimum
solution. Furthermore, I was suggesting that calling code with
side effects *in* the log expression is fraught with peril.
In the general case, one might really need to write
if (logging this level, subsystem, etc.)
do various things including logging messages
> 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
That needs to be highlighted.
> * 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.
As do I.
-- Rob Stewart stewart_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk