Re: [boost] [Serliazation] Thread-safety again

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-01-03 13:08:15

David Abrahams wrote:
> "Robert Ramey" <ramey_at_[hidden]> writes:

>> I don't see how one can determine at compile time whether or not an
>> object of a particular type is going to be used.

> It has nothing to do with whether an object "of a particular type" is
> going to be used; it has to do with whether objects **defined in the
> translation unit** are used.

>> In fact, it may
>> well vary from one exectution run to the next.
>
> So what?  The compiler/linker make that determination, and for code to
> be stripped they don't need to determine precisely whether all objects
> are used or not it's sufficient for them to be able to prove that
> certain objects *won't* be used.  That is sometimes provable, so
> initialization code is sometimes skipped and/or stripped.

> Can you answer the question?
>
>   Did you intend that proper registration occur even if no objects or
>   functions from the translation unit containing the EXPORT are used?

Hmmm - there are a couple of things going on which are a little confusing:

a) instantiation of code to serialize data type T with archive A.  This may 
include
(I forget the exact names) basic_archive_serializer<A, T>.  It was my 
intention that
this code be instantiated for all combinations of archive types and data 
types
actually used and no others.  This the fundamental function of 
BOOST_CLASS_EXPORT

b) construction of an instance void_caster for each pair of types B and D 
where
D is B is a base class of D.  This is the function of .. 
BOOST_SERIALIZATION_BASE_OBJECT_NVP

c) construction of an instance of extended_type_info for type T which is 
used to support
the above.

So, if I make a program which loads objects of derived class D through a 
pointer to
base class B  I will need the above described code to be instantiated even 
though
no calls the the functions in the header containing EXPORT are explicitly 
made.  If
this code isn't found at runtime - due to code stripping - the program will 
through
an "unregistered" exception.  This is how it is intended to function and is 
indeed
how I believe it functions on the compilers we test with.

>> So the extended type info table has to be initialized with all the
>> types that might be in the archive.  This is what export attempts
>> to do.
>
> It doesn't do enough, and there is no portable thing it can do that
> would be enough.

Hmmm - well it does work.  But I DID have to include "_export" - non
portable construct to make it work - that is the function of the 
"force_include.hpp"
header.

> The documentation should describe the limitations on portability of
> relying on the export code being registered even if nothing else in
> the TU is used, and should describe how to ensure that it does get
> registered

Well, that's an easy fix.

On the other hand, I don't know that all
compilers will correctly implement this behavior.  For example, will
VC behave as expected when "function level linking" (which I
always use and test with) is enabled?  Only testing can really
resolve this.

> (just call a little stub function in the TU from main()).

I can already hear the howling in the distance.  If one can do this
the it would be just as easy to explcitly the all the derived types
at the beginning of an archive and avoid BOOST_CLASS_EXPORT
all together.

Then there is the question of dynamically loaded DLLS which
is involved here.  Given that is is OS dependent,  I expect the usage
of dynamically loaded DLLS is not portable in any case so
its easy to address just by so indicating in the documentation.

In any case, its easy to add this explanation to the documentation and
I will do this.

>> Well, that would explain one reason we've had so much problem
>> with this comipiler - its too conforming!!!

> You clearly forgot the smiley.

I'm not sure I meant that as a joke.

BTW, in the latest HEAD cw tests
there are only two tests failures (excluding a couple of failures due
to artifacts of the tests).  So I'm thinking that this is going to a non
issue for all practical purposes.  On the other hand, I don't think
the tests have been run with this compiler in release mode so its
not a real test.  On the other hand, if this compiler has the capability
to build windows DLLS, it has to have something like the _export
keyword.  Currently, force_include.hpp doesn't include anything
like this for CW but maybe it could.  Note that other compilers
in wide usage (MS, Borland, GCC) all include some syntax
for addressing this issue. The header force_include.hpp
defines macros for inserting this syntax in the proper place
for each compiler.  I'm surprised that no other libraries that
I know of have not had this problem.  If it were more common
I would expect something like "force_include.hpp" would
be needed at the Boost level rather than the BS level.

As an aside - sort of - implementing serialization in a way which meets the
expections of most programmers - as reflected on this and the user list
could not be done without a number of contortions.  I would be interesting
to consider what changes/refinements to the C++ language would be helpful in 
making
a better system of this type.  Aspects of this are in

a) extended type info - not portable external representation of a type and
not an obvious way to handle namespaces.
b) code instantiation in certain case like the above
c) sequence of intialization constructors
d) DLLS and all of the above.
e) compile time reflection

Robert Ramey