From: Robert Ramey (ramey_at_[hidden])
Date: 2005-09-02 11:11:49
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk