David Abrahams wrote:
on Mon Jul 28 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
Robert Ramey wrote:
The reason I ask is that the serialization library uses spirit to parse xml archives. Recently, I made changes to make the library thread-safe. I did this without using mutexes/locks by confine all non-const operations to construction and destruction and using static object constructed/destructed at pre-main and post main time time. Although the jury is still out on this, I believe it will make the serialization library thread safe without the need for using threading primitives and libraries.
What happens if one explicitly loads a dynamic library, which uses serialization? I'd guess the types serialized by that library should be added to the global table of serialized type (at least for types marked with BOOST_CLASS_EXPORT), so it's non-const operation done after main. Am I missing something?
Suggestion: handle that by deferring the availability of the registrations associated with that DLL until the user explicitly says it's safe to add them. The idea is that every DLL adds things to its local registry and in a MT application, that is only combined with the global registry via an explicit call, when presumably the user knows no threads are doing serialization.
How deferring registration of serialization is better/easier than deferring loading of DLL itself. Suppose that application, in response to user's action, decides to load a plugin and call a function there, *now*. Then, either you need to: - load DLL - call a function or: - load DLL - tell it to register all serialized classes - call a function and if should be done while some other thread is potentially busy doing the same, I don't really see practical difference between those two approaches. - Volodya