Kim Barrett wrote:
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.)
So, we have received only anecdotal data on where such performance bottlenecks might be.
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.
I'm pretty sure that intertwining runtime DLL loading with all of our clients of the serialization library is just not going to fly
Note that as presentlly implemented an archive used for marshalleling something like IPC transaction would be a short operation - open archive with a string stream, serialize, close archive, send string to ipc connection. My previous suggested solution of deriving from an existing archive class an adding would work very well in this case and be indistinguishable from a solution which built threading in at a lower level.
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,
I yet see no reason to change my view.
or to obtain or develop a patch and carry it forward.
Good luck, Robert Ramey