Steven Watanabe wrote:
a) If serialization code for some class is in a DLL and this DLL is dynamically loaded/unloaded while some other archive is open and being used by a separate thread, there could be a problem. This would be due to the fact that there is global list of types which is updated when a DLL is loaded and/or unloaded.
It's blowing up when trying to read the serialization header. I don't think this has anything to do with the type being serialized.
b) xml_iarchives depend upon spirit which is not guarenteed thread-safe. I looked at the spirit code and believe that I selected that part which was thread-safe. But at least one user noted an issue with loading multiple xml_iarchives from separate threads.
It's a binary archive.
I'm aware of these facts. My real point is that the effort is mis-directed. It's much, much easier and cost-effective to compose components independently proven to be correct than it is to just patch together a bunch of stuff and try to trace backward from the symptoms when it fails. I'm absolutely sure that the amount of effort required to implement my suggestion would be far, far less than the effort so far expended. (I'm not even count your's and my efforts in trying to respond to a post which says (paraphrasing) "My binary serialization doesn't work, what could I be doing wrong?" The uttering of this sentence, reveals the crus of the real problem which is one is going about the task of creating correct software from exactly the wrong end. Robert Ramey