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: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker@tab.at http://www.tab.at