[boost] Candidate logging library and static initialization/destruction

From: Matthew Herrmann (matthew.herrmann_at_[hidden])
Date: 2007-11-22 17:28:29

Hi,

I have a question for the author of the logging library on the boost 
review queue regarding static initialization and destruction.

I currently use the logging library that was rejected at the last 
review, and I noticed some issues with it relating to handling 
destruction in a static context. Specifically, I'd get occasional 
segfaults if I declared an item in static scope that logged in its 
destructor. Once the object was moved to within the main() function, the 
issue went away. I'm not sure if it was the logging library, or our use 
of it, but it was a bit of an issue since it made the use of logging 
less transparent to clients of my library code.

I can see from the documentation that you have given quite a bit of 
thought to multithreading concerns. Have you also considered issues 
around static initialization and destruction?

In particular, a class that performs logging in its constructor and 
destructor should still behave correctly when instantiated in a static 
context. I think the problems I had with logging before related to the 
logging data structures being torn down in the static destruction phase 
before my own objects.

The way I solved that in a (far more limited!) logging library for our 
own use was the following:

- Never destroy the logging data structures -- allow them to leak. No 
risk of static ordering issues.
- In the static initialization case, initialize the logging structures 
on first access, and if not accessed during the static context, 
guarantee that they are initialized before main() is called.

To do that, I essentially borrowed the implementation of the boost pool 
singleton, except that I removed the destruction:

http://boost.org/libs/pool/doc/implementation/singleton.html

Anyway, I would appreciate hearing your thoughts on this area as I'd 
like to use version 2!

Many thanks,
Matthew Herrmann