From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-17 19:13:58
> Robert Ramey wrote:
>> I'm still considering this. I'm a little bit concerned about what
>> when there are multiple instances of extended_type_info for a
>> 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
> 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
>> Calls to the library should be wrapped in there own locks. I would
>> that the top level entry points to serialization would be few in
>> 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
I disagree - see above.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk