On Mon, 2007-05-21 at 20:04 -0700, Robert Ramey wrote:
Sohail Somani wrote:
Thanks for your quick response. Could you point me to the files that have been changed to address the issues?
You'll have to browse the CVS - look into extended type info
I am looking at: http://boost.cvs.sourceforge.net/boost/boost/libs/serialization/src/extended_type_info.cpp?r1=1.11&r2=1.12 which I assume is the change you are suggesting. This still doesn't address the thread-safety issues inherent in Myers Singleton that is used here: http://boost.cvs.sourceforge.net/boost/boost/boost/serialization/extended_type_info_typeid.hpp?revision=1.9&view=markup on line 96. With the above code, it is possible to have double initialization of the extended_type_info derived instances and then eventually double initialization of detail::*map which could be a more dramatic error. So if anyone uses BOOST_CLASS_EXPORT() you cannot reason about your program's thread-safety. I was sent a patch privately by someone who changed the instance in the first link to be a class member static with a caveat that it invokes "dynamic initialization." I am new to the whole C++ language lawyer thing but in section 3.6.3(.3) of the standard, it says: It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace scope is done before the first statement of main. So I really don't think there is any way to do this lazy initialization portably in the presence of threads (threads? what are those?) However, the choice to delay it to a function-scope static makes it easier to make it work. I can develop a patch using boost once that I think would work. Locally, I'm going to have to do this anyway. Fortunately, my test has ceased to fail so I can't test it. To make it as "pay for what you use", one can #ifdef it out if they have special knowledge of the platform/compiler. Suggestions, comments or flames? All three are appreciated. Sohail