Date: 2005-09-05 03:30:38
<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
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
> 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
> with a catestrophic untraceable error should he make a mistake in this
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.
>> 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
> of a given type in different DLLS and have those DLLS simultaneously
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
>> different DLLS which are to be simultaneiously loaded defeats the whole
>> point of DLLS in the first place - to avoid having memory loaded with
>> (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.
Phone: +43 7229 78040-218
Fax: +43 7229 78040-209
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk