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