Hi, Robert Ramey wrote:
I'm still considering this. I'm a little bit concerned about what happens when there are multiple instances of extended_type_info for a specific type in the global table.
When unregistering from the global type registry the type info address should be used. But when comparing type info objects for equality, for example when performing void casts, it shouldn't. I agree that it's not the nicest solution and this should be given some more thought.
Finally, I'd like to bring your attention to the issue of thread safety. Since Boost.Serialization has a number of global objects, access to them should be safe-guarded by a synchronization primitive, such as a mutex.
This is something that should be left outside the serialization library.
Calls to the library should be wrapped in there own locks. I would expect that the top level entry points to serialization would be few in number and that each of these would have its own locks. I see no need to include locks withing the serialization library itself.
I strongly disagree. This requires the client to know implementation details of the library. The library should at least guarantee basic thread safety, so that two threads can use two different archive objects at the same time, which currently is not necessarily the case. If we use dynamically loaded DLLs and use multiple threads to do so, for example, we need to lock _every_ call we make to Boost.Serialization. Given that some of these calls are hidden in static global variables, i.e. behind the BOOST_CLASS_EXPORT macro, it is not even possible for us to perform this locking at such a granular level. How about making this an optional feature via a #define? Adding the locks to the code is quite straightforward. I can provide you with a patch, if desired. Best Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker@tab.at http://www.tab.at