Particulary, I had problems with unregistered base-derived casts when tried to use multiset implemetation of tkmap and base or derived was registered from more than one dll. I had attached modified files that resolves it. The main issue is comparison of void_casters and basic_serializers, but there are also a couple of some less important changes like purging of void_caster_registry and correctness of basic_archive_impl::helper_compare.
Also, there are one still unresolved issue with multiple registration - sometimes loading failed if type serialized by value in one exe/dll and by pointer in another. I had not discovered this situation completely, but found that this occurs because loading code tries to read tracking info that absent in file (or the contrary). Fortunately, it is easy to write never-called-function that "loads" problematic type by pointer and place it to dll. But some kind of assert to recognize such a situation would be very usefull.
"Robert Ramey"
Even though they happen to intersect at the same spot - There are two separate issues.
a) The need for a thread-safe singleton b) the properway to handle multiple registrations for dynamically loaded code.
I thought I addressed the second. (Now you've made me doubt that). The first is still an open issue.
Robert Ramey
Sergey Skorniakov wrote:
Thanks for your quick response. Could you point me to the files that have been changed to address the issues?
You'll have to browse the CVS - look into extended type info
I am looking at:
http://boost.cvs.sourceforge.net/boost/boost/libs/serialization/src/extended_type_info.cpp?r1=1.11&r2=1.12 which I assume is the change you are suggesting.
I have tried this variant and it doesn't work with multiple-registred classes (from diferent DLLs) even in single-threaded environment. multiset is not enough because comparison of different instances of extended_type_info of the same double-registred class still returns false. I have changed my local copy of serialization library to properly handle multiregistration, however my solution is not threadsafe in general - it just works in one particular case. If someone interested in it, I can send the patch against 1.34 version.