martin.ecker@tab.at 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