Re: [boost] Re: Boost.Threads draft library submission

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-03-17 20:58:40

From: Jeff Garland <jeff_at_[hidden]>
> > > For fault resilient applications a typical strategy in libraries
> > > is to assert during unit testing and throw an exception
> > > in integration test and production.  In production the exception
> > > is something like std::logic_error.  Usually a macro handles
> > > the conditional compilation of the library.
> >
> > An application that must run 24x7 that's written in C or C++ pretty much must
> > have an automatic restart mechanism for robustness in any case.  In server
> 
> Yes, but restart is often the second layer of defense not the first.
> There are plenty of times when the whole application doesn't need to crash just
> because of a software error.
> 
> > intervention.  With the compilers I use, exceptions make it impossible to
> > generate a useful core dump that shows precisely what happened.  I'd
> > rather have the core dump in the case of a logic error.
> 
> I prefer to core dump too, but again not every application can
> take this approach. So, not making this an option will
> exclude the use of Boost.threads (and the Boost libraries
> which depend on boost threads) from those applications.
> Just as a point of reference, I don't think there are any
> C++ standard library implementations that take the assert
> approach.

In the Oracle server we avoid dumping core in production code, since
core files are so huge, but we do what takes on each platform to
generate a stack trace to a log file before aborting a transaction,
killing the server process, and starting up a new one.  We also
treat anything that can so crash the server as a priority one bug.

In development code we contrive for assertions to generate a SEGV
and a core to allow for debugging after the fact.  But performance
is critical so we turn off most assertions in production code.