Re: [boost] [Serialization] (Commented) assertion when using types in multiple DLLs on Windows (Ticket #3934 and #4394)

Subject: Re: [boost] [Serialization] (Commented) assertion when using types in multiple DLLs on Windows (Ticket #3934 and #4394)
From: Martin B. (0xCDCDCDCD_at_[hidden])
Date: 2011-12-14 06:59:34

On 14.12.2011 09:19, Martin B. wrote:
> On 14.12.2011 09:03, Martin B. wrote:
>> On 13.12.2011 18:22, Robert Ramey wrote:
>>> Martin B. wrote:
>>>> [Serialization] (Commented) assertion when using types in multiple
>>> (...) (...)
>>>> ## Question: Solutions?
>>>> (...)
>>> I would like to see you invest some more effort to see
>>> exactly where the extra registration comes from.
>>
>> Well, see my call-stack above and I'll dump a sourcecode sketch below.
>> This does reproduce the thing for me, but other that ignoring the assert
>> (upgrading to boost 1.48) I haven't tried any approaches yet.
>>
>
> Okay. Now, for this my testproject, I have been able to make it "just
> work" without the assertion by:
>
> 1. Removing the Types.cpp file from the executable (this will obviously
> initially give an unresolved external warning for Derived::* members)
>
> 2.) Make Derived a DLL export class, that is:
> class DLL_API Derived : ...
> with the usual (...)
>
> To my surprise it compiles, links, and runs correctly. (And the type is
> only registered once, namely from the DLL.)
>
> Now I'll just have to check if this solution can be applicable for our
> real projects, where we currently use BOOST_CLASS_EXPORT() instead of
> the split versions and we have a multitude of derived classes.
>
> So maybe the assertion made sense after all. (Though I think this should
> be configurable on a type by type basis should it ever be reenabled.)
>

OK, we have now adapted our real project types and it seems it's working 
out well.

So, to summarize:

* The notification *makes* kind of sense, although it really isn't an 
error[1] but a nice warning and so the *unconditional* assert is rather 
inappropriate I think.

* I guess the situation as it stands with the disabled assert is better 
that the situation before with the unconditionally enabled assert. For 
future improvements, I think that the BOOST_CLASS_EXPORT_* macros need 
to provide a way to specify the desired checking level on a case by case 
basis. (And the appropriate documentation for the firing assertion.)

* Making these Types DLL-exported and defining their implementation only 
in the DLL worked for us, and in general, should probably work for most 
types where this problem occurs, because in this context you already 
have the situation of multiple DLLs+EXE, and you're just moving the 
implementation of the type to a single place.

* [Speculation on my part:] If the types live in a static lib that is 
used by different modules of the same process, things do get more 
complicated, as it then should be more difficult to DLL-export the 
types. But maybe one could work around this by not using the 
serialization lib as a DLL but instead as a static lib. (Obviously would 
lead to code bloat, but you're already living with duplicated 
implementation code for the types in each module in this case anyway.)

[1]: Wrt. "not an error" - The assertion was harmless for our code, but 
the situation could (I have not tested it) be potentially disastrous for 
dynamically loaded and unloaded DLLs that use the same types as another 
module in the process. If I understood correctly, if the serialization 
registration is done twice for a type, the first DLL to use it and being 
unloaded will unregister the type, thus breaking serialization for this 
type for all other modules. I haven't reproduced this, so it's largely 
hypothetical at this point (are there any open tickets wrt. this?). I'm 
also still unsure if only those types that use BOOST_CLASS_EXPORT are 
affected by this problem.

cheers,
Martin