Re: [Boost-bugs] [Boost C++ Libraries] #5341: Patch to improve shared library behavior with serialization

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #5341: Patch to improve shared library behavior with serialization
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-04-23 21:59:00

#5341: Patch to improve shared library behavior with serialization
----------------------------------------------+-----------------------------
  Reporter:  Aaron Barany <akb825@…>          |       Owner:  ramey                              
      Type:  Patches                          |      Status:  reopened                           
 Milestone:  To Be Determined                 |   Component:  serialization                      
   Version:  Boost 1.46.0                     |    Severity:  Problem                            
Resolution:                                   |    Keywords:  serialization shared_libraries dlls
----------------------------------------------+-----------------------------

Comment (by Aaron Barany <akb825@…>):

 a) It does handle when the serializer for class A is instantiated in
 multiple DLLs. The map type has changed from a set to a multiset, which
 allows multiple serializer instances for the same extended_type_info. In
 order to understand this, you will also have to look at
 archive_serializer_map. I wrote this patch because my use case was
 encountering the situation of having multiple serializers instantiated for
 type A, and it was failing because the pointer serializers for class A was
 set in one DLL, but not in another, causing confusion as to whether or not
 the instances for that type should be tracked.

 Here's a step by step example of what happens at various stages of
 initialization and sutdown:
 1. A serializer for class A is instantiated in a new DLL.
    a. The serializer is registered with the archive_serializer_map. Since
 it is a multiset, it will be in addition to existing serializers for type
 A.
    b. It looks at an existing serializer registered for class A. If it has
 a pointer serializer, it re-uses that pointer serializer for the new
 serializer being registered.
 2. If a pointer serializer for class A IS NOT instantiated in the same
 DLL, everything works since it is using a pointer serializer from a
 different DLL, keeping the state consistent.
 3. If a pointer serializer for class A IS instantiated in the same DLL.
 (NOTE: This is guaranteed to happen after the serializer is instantiated)
    a. It assigns itself to the serializer of A. This ensures that the
 serializer for class A always prefers the pointer serializer in the same
 DLL it's instantiated in.
    b. It looks at the existing instances of serializers for class A, and
 if they have no pointer serializer it uses the current pointer serializer
 being initialized.
 4. A pointer serializer for class A is destroyed.
    a. It looks at the existing instances of serializers for class A, and
 tries to find a pointer serializer that isn't the one being destroyed.
    b. For all serializers for class A, if it is using the pointer
 serializer being destroyed it uses the replacement found in step a. If no
 replacement was found, NULL is assigned.
 5. A serializer for class A is destroyed, it is simply removed from the
 archive_serializer_map.

 These steps ensure that either all serializers for class A have a
 corresponding pointer serializer or none do, eliminating the case where
 some serializers for class A would have a pointer serializer and some
 wouldn't. The trap is no longer necessary, as this solution specifically
 handles the case that was breaking before.

 b) As already mentioned by Steven, it is part of the standard. Here's the
 documentation for it.
 (http://www.cplusplus.com/reference/stl/multiset/equal_range/)

 c) equal_range is used by the new implementation of archive_serializer_map
 for the operations that look at all existing serializers for a specific
 type.

 The additional macros in text_iarchive.hpp are necessary to properly
 export the symbols for the archive_serializer_map. This is what I was
 explaining earlier, where you need to specify per library whether or not
 to export the symbols for the archive_serializer_map in order to allow
 creating custom archive types. The way it was before, it was hard coded to
 only export from the boost serialization DLL.

 It might be possible to eliminate the need for a separate
 archive_serializer_map instantiation for every archive type, but that has
 two requirements. First, it would require a lookup based on the archive's
 extended_type_info, adding an additional lookup every time you need to
 lookup a serializer in the archive_serailizer_map. Second, the serializer
 type hierarchy would need to be redone to allow querying the pointer
 serializer without knowing the archive type.

 As for my patch, I can probably make two separate patches: one for the
 changes supporting multiple serializer instantiations, and one for the
 different DLL import/export changes. I won't be able to split it up any
 further and have it still function, though.

 I would like to see the list of issues you want to see addressed. We rely
 heavily on serialization in the codebase I'm working with, so having the
 opportunity to fix issues we may run into later will be a win-win.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/5341#comment:9>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.