Re: [boost] [serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-17 19:13:58

martin.ecker_at_[hidden] 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