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

From: martin.ecker_at_[hidden]
Date: 2005-09-05 03:30:38

Hi,

<snip my comments on how to make sure all the global objects, such as 
type info and void caster objects, are always unique in a process>

Robert Ramey wrote:
> Wouldn't this require that the first DLL loaded be the last one to be 
> unloaded? 

No. The order of loading/unloading DLLs doesn't matter. The first time 
a DLL is loaded that contains a BOOST_CLASS_EXPORT (and with it a 
number of global objects, such as type info), the global objects that 
need to be registered with the global registries and maps are created 
for the first time. Since they are reference counted, these process-
wide unique, global objects only get destroyed when the last reference 
to them is released - for example, when the last DLL that uses them 
gets 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?

No, there are no requirements on user code or DLL loading/unloading
order. My proposed scheme should simply "just 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.

Yes.

>> 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. 

But there's nothing you can do about it. As soon as serialization 
code, in particular some global objects such as type info, are in a 
header file and that header file is included in code in multiple DLLs, 
you _will_ definitely get multiple copies of these objects (on Windows 
at least). That's why my proposal is to let these global objects only 
be some kind of smart reference and have the "real" global objects 
that need to be unique for the running process be created by the 
Boost.Serialization DLL only once. Currently they are potentially 
created multiple times in the above scenario (i.e. serialization code 
in a header file that is included by code in multiple 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.

I agree with this. But because of the way the Windows DLL loader works 
in combination with global variables declared in C++ header files that 
are included by code in multiple DLLs, you cannot prevent having
multiple instances of global variables.

Regards,
Martin

TAB Austria
Haiderstraße 40
4052 Ansfelden
Austria
Phone: [phone]
Fax: [phone]
E-mail: martin.ecker_at_[hidden]
http://www.tab.at