Candidate logging library and static initialization/destruction
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
Hi Matthew,
Hi,
I have a question for the author of the logging library on the boost review queue regarding static initialization and destruction.
That would be me ;)
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 have encountered this as well - in v1. Right now, in v2 - at this time I'm not handling this. However, it's a must have to be in there (see todo.html - on the code in SVN). So, within a week - this feature will be present.
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?
Yes I have. As a side-note - if you could trim down the example and send it to me, that would make it easier for me to test ;)
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
Yes, that is true.
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
Note: at this time, there are no problems at the logs' construction (related to segfaults or anything) - however, if you log from a constructor, nothing happens. This needs to be fixed.
Anyway, I would appreciate hearing your thoughts on this area as I'd like to use version 2!
So would I ;) Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
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.
Why not provide initialization and clean-up functions and let the user call them explicitly? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
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.
Why not provide initialization and clean-up functions and let the user call them explicitly?
In v2, this is handled quite differently. So it doesn't apply - but I have to come up with a solution :) Best, John -- http://John.Torjo.com -- C++ expert ... call me only if you want things done right
participants (3)
-
Emil Dotchevski -
John Torjo -
Matthew Herrmann