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
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
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
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.
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
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.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:06 UTC