Michael Marcin wrote:
As I recall, the problem with the thread-safety of the serialization library relates to setting up the type info maps. If you could somehow create a way that one could invoke the setup of this map perhaps by a function call, that would solve the problem, yes?
Actually that's what happens now under the covers. This occurs in a number of different places - each in its own way. This can be factored out into a common singleton implementation. Replacing this common one with a threadsafe version will make the serialization truely threadsafe.
That sounds good to me. If the serialization library is doing something non-trivial at static initialization or destruction time than it can't be used in many embedded environments that either don't perform static destruction or require a explicit initialization of their runtime library, free store/heap, etc.
Then all you'll have to do is replace the trivial singleton implemenation with your own which addresses you particular situation. Robert Ramey