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

Subject: Re: [Boost-users] [Serialization] Inconsistent tracking_level when switching from static to DLL
From: Guy Prémont (guy.premont_at_[hidden])
Date: 2010-12-07 16:52:33

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

--
Guy Prémont, D.Sc.
Architecte logiciel senior / Senior software architect
CM Labs Simulations Inc. http://www.cm-labs.com/
Tel. [phone] ext. 237 
> -----Original Message-----
> From: boost-users-bounces_at_[hidden] [mailto:boost-users-
> bounces_at_[hidden]] On Behalf Of Robert Ramey
> Sent: Wednesday, December 01, 2010 3:21 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] [Serialization] Inconsistenttracking_level
> whenswitching from static to DLL
> 
> Guy Primont wrote:
> >> This is a result of the serialization library maybe being a little
> >> too smart for it's own good.
> >>
> >> The default behavior is to track if serialized as a pointer.  This
> >> could vary if one invocation uses serialization of pointers and
> other
> >> doesn't.  At one point I included code which would trap when the
> >> serialization code for same type appeard in more than one DLL.  This
> >> fixed the problem, but it required that users organize their code so
> >> that serialization of a specific type be included in one and only
> one
> >> DLL.  This turned out to be too onerous a requirement so I had to
> >> comment out this check.
> >>
> >> So, I'm going to guess that the safest thing is for such types is to
> >> either turn tracking off or on rather than using the default.
> >>
> >> Robert Ramey
> >>
> >>
> >
> > Thanks, it is what I thought. I am curious about the trap to check if
> > serialization code is in several DLLs. What kind of code organisation
> > are you talking about?
> >
> > In my case, the serialization code for a class T is in only one DLL,
> > but it is used called by each DLL that contains serialization for a
> > class that uses class T. The method T::serialize is in only one DLL.
> >
> > However, if class A has a member of type T it would have
> > template<typename Archive> void A::serialize(Archive& ar, int
> version)
> > {
> >    ar & t; // where t is a T
> > }
> > As far as i see, it is the invocation of serialization in a serialize
> > method (ar & t) that triggers the creation of the o/iserializer for
> > type T. Is that it?
> 
> It is so you'd better use
> 
> template<typename Archive>
> void A::serialize(Archive& ar, int version); // note ;
> 
> and include the difiniiton in the DLL
> 
> This is a murky area which I spent a fair amount of time investigating
> some time ago.  Now I don't remember what my final conclusions were.  I
> thought the problem manifested it self in as "unregistered class"
> exception so that in the absense of that, one could assume everyhing
> was kosher.
> 
> Robert Ramey
> 
> 
>