martin.ecker@tab.at wrote:
Hi,
Robert Ramey wrote:
I'm still considering this. I'm a little bit concerned about what happens when there are multiple instances of extended_type_info for a specific type in the global table.
When unregistering from the global type registry the type info address should be used. But when comparing type info objects for equality, for example when performing void casts, it shouldn't. I agree that it's not the nicest solution and this should be given some more thought.
I very agree here. Another idea is to just prohibit more than one DLL to register an extended_type_info object. This could be trapped. In general, I'm wary of overly tricky solutions to address relatively obscure and uncommon cases. (Though I suppose that might not be apparent from looking at the serialization library).
Finally, I'd like to bring your attention to the issue of thread safety. Since Boost.Serialization has a number of global objects, access to them should be safe-guarded by a synchronization primitive, such as a mutex.
This is something that should be left outside the serialization library.
Calls to the library should be wrapped in there own locks. I would expect that the top level entry points to serialization would be few in number and that each of these would have its own locks. I see no need to include locks withing the serialization library itself.
I strongly disagree. This requires the client to know implementation details of the library. The library should at least guarantee basic thread safety, so that two threads can use two different archive objects at the same time, which currently is not necessarily the case.
I believe that this is the case. The only shared global objects are collections of extended_type_info objects and base/derived registrations (void_cast_primitives). These collections are built/modified only during pre-execution or during loading/unloading of DLLs which export types or void_cast_prmitives. So I believe your concern could be addressed by a code which inhibited loading/unloading of DLLS while any archives are open. I don't think this has to be part of the serialization library.
If we use dynamically loaded DLLs and use multiple threads to do so, for example, we need to lock _every_ call we make to Boost.Serialization. Given that some of these calls are hidden in static global variables, i.e. behind the BOOST_CLASS_EXPORT macro, it is not even possible for us to perform this locking at such a granular level.
I disagree - see above. Robert Ramey