Re: [Boost-users] [Serialization] Inconsistent tracking_level whenswitching from static to DLL

Subject: Re: [Boost-users] [Serialization] Inconsistent tracking_level whenswitching from static to DLL
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-12-08 12:03:01

Guy Prémont wrote:
> Hi,
>
> I have work more on the problem of inconsistency of pointer tracking
> AND pointer serialization when using several DLLs that contains
> serialization code.
>
> Some pseudo-code is attached to illustrate the complete situation. In
> brief, a DLL_SERIALIZATION_CORE.dll contains archive types and the
> serialization code for several classes. A
> DLL_SERIALIZATION_EXTENSION.dll contains serialization code for
> additional classes. Classes serialized in the extension DLL use some
> object from the core DLL.
>
> When building and linking with static library, all is working fine.
>
> CORE.dll serializes class A as a pointer and as an object, both
> i/oserializer<> and pointer_oserializer<> singleton are created.
> EXTENSION.dll serializes class A as an object only, i/oserializer<>
> singleton is created.
>
> Depending on the ordering of serialization during loading, it happens
> that basic_iarchive_impl::register_type() overwrite the
> pointer_iserializer that was set in by the CORE dll.
>
> When saving, automatic tracking level is not correctly deduced since
> the pair oserializer<>/pointer_oserializer<> is created per DLL.
>
> There seem to be a clear need for a centralized repository of
> i/oserializer for each type, so that all DLLs use the same ones. In
> addition, using type_info::before() to order a std::map<> does not
> seem to be working. At least with windows VC9, before() just orders
> according to the address of typeinfo*; since a DLL creates a typeinfo
> object for each type it contains, using the same type in different
> DLLs can not be ordered with typeinfo::before()
>
> I've been working with Boost.Serialization for a while now. I'm really
> impressed with the ease of use, the scalability, and the power of the
> library. However, splitting the serialization code in several DLLs,
> although working for simple cases, have shown several problems. In
> static libs, boost serialization is extremely robust, in DLLs,
> several issues needs to be addressed to have the same robustness.
>
> Looking at my pseudo-code, maybe that I am not using the library as I
> should. I would be grateful for any hint or information.
>
> Thanks
> Guy

As I've said before, I believe that this occurs because the code to
serialize some data types is included in more than one code module
(dll or exe).  I would re-organize my code so that this does not
occur.

There is code in the library which will detect when code to serialize 
particular
data type is included in more than one execution module (dll).  This code 
will
trap with an exception when a dll with duplicate code is loaded.  This would
enforce and detect violations of the above rule.  Unfortunately, I had to 
comment
out this code because many found this requirement to hard to implement
and didn't have any problems.

I would recommend finding and uncommenting this code and rebuilding
the library.  This should trap violations of the above and help you 
re-organize
the code to be rock-solid.

If I had nothing else to do, I would uncomment the code to re-enable the
trap and add a runtime archive switch (like no_header) to suppress the trap
for those who wish to.  But, I have other stuff to do right now.

Of course, it could be an entirely different problem, but as long as the 
current
situation exists, I can only speculate.

Robert Ramey