Re: [boost] [serialization] Boost.Serialization1.33.0BreaksSerializationCode inDLLs

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-09-02 11:11:49

martin.ecker_at_[hidden] wrote:
> Hi,
>
> Robert Ramey wrote:
...
> So now we don't have any problems when DLLs that contain serialization
> code for type T get unloaded. They simply decrease the reference count
> to the pointer_iserializer object. When the last DLL gets unloaded,
> the reference count drops to 0 and Boost.Serialization can destroy
> the pointer_iserializer object for type T.

> I believe, this approach should work with all types of global objects,
> i.e. void_caster, pointer_iserializer, pointer_oserializer, and
> extended_type_info. It should also work in all situations I can think
> of with DLLs on Windows, i.e. with DLLs loaded at startup and unloaded
> at shutdown and with DLLs that are loaded/unloaded explicitly during
> run-time.

Wouldn't this require that the first DLL loaded be the last one to be 
unloaded?  How would such a requirement be enforced?  Wouldn't this put a 
burden one the library user to load/unload his DLLS in a certain sequence 
with a catestrophic untraceable error should he make a mistake in this area?

>> I'm thinking that the best would be to detect the case when a
>> duplicate extended_type_info record is added to the corresponding
>> global map and throw an exception.  I see no other way at this point
>> to guarentee that the system will always work.

> This would break all our current code base. When you use DLLs and you
> have serialization code in one DLL that is then used by another DLL,

For the same type I presume.

> then -with the current use of (effectively global) static member
> variables in e.g. pointer_iserializer - you _will_ get multiple
> objects registered in the global registries and maps. There's nothing
> you can do about that (at least not on Windows; I believe with the
> Linux loader this problem does not occur). Throwing an exception if
> this happens, makes using Boost.Serialization with DLLs impossible.

This would make it an illegal detectable error to include the serialization 
of a given type in different DLLS and have those DLLS simultaneously loaded. 
That is, this would enforce the One Definition Rule (at at time) for 
dynamically loaded DLLS.

Although its a user issue, I would think that including the same code in 
different DLLS which are to be simultaneiously loaded defeats the whole 
point of DLLS in the first place - to avoid having memory loaded with dead 
(or sleeping) code.

Robert Ramey