[boost] [serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs

From: Kim Barrett (kab_at_[hidden])
Date: 2005-08-19 18:07:28

I've been reading this thread with increasing alarm. I agree with
Martin Ecker and Vladimir Prus that the synchronization in question
belongs inside the serialization library.

The system we are building will have several inter-process
communication mechanisms, which I'm hoping to be able to build on top
of Boost.Serialization. (As noted in another thread, I've run across
some performance issues, which might be addressed by resetting and
reusing archives, rather than constructing new archives all the time.)

It is expected in our system design that it will be possible to
dynamically load DLLs containing new types which support
serialization, and then create new IPC connections (with associated
archives) to/from which instances of those newly loaded types can be
serialized. It is not a requirement that previously existing IPC
connections (and their associated archives, either presently in use,
or available for reuse if archive resetting is used) support these new
types, since the type information for the connection is specified at
connection creation time. We expect a substantial number of such
connections to exist at any one time, with many threads involved, and
they have some latency requirements. We presently plan to punt support
for unloading DLLs, on the basis that the benefit (in our system)
would be small compared to the design / implementation / documentation
cost for supporting unloading safely and correctly. (We might revisit
the decision about unloading, but for now supporting it is not a
requirement for us.)

I'm pretty sure that intertwining runtime DLL loading with all of our
clients of the serialization library is just not going to fly. I think
that making it a configuration option whether the library protects its
internal data structures is a reasonable approach, since some
applications won't need it (either because they are single-threaded or
are willing to deal with the issues at the application level) and
might not want to pay the cost. But for some applications, having the
library be responsible for the consistency of its internal data
structures is really the only realistic option. I think the only way I
will be able to sell the use of the serialization library for our
project is to either convince you to change on this issue, or to
obtain or develop a patch and carry it forward. The latter might be
less work in the long term than developing the subset of serialization
features that we actually need, but the long-term maintenance headache
for a patch is worrisome.