Hello Robert, Robert Ramey wrote:
I would like to add a couple of new tests to test this kind of thing. You don't have anything suitable for this do you?
Unfortunately, I don't. The only "test case" we have is our entire system itself, which is a bit too big I'm afraid. Basically, it would be beneficial to add a DLL to the test suite and then write the following test cases: - Put serialization code in the DLL for a class A. Then serialize an instance of class A first from code in the DLL and then from an executable that links with the DLL. - Derive a class B from class A in the DLL. Serialize an instance of class B via a base class pointer to class A from code in the DLL and from an executable that links with the DLL. 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 particularly important for us when dynamically loading DLLs. For example, we load and unload DLL plugins during runtime, and we have multiple threads that use Boost.Serialization (potentially also while one thread is currently loading a DLL). Before I added mutexes to all global objects in Boost.Serialization, we had random crashes when one thread was dynamically loading a DLL while another thread was reading/writing a Boost.Serialization archive. This is because the global objects in Boost.Serialization are potentially modified while the DLL is being loaded (e.g. if the DLL that is loaded contains BOOST_CLASS_EXPORT macros somewhere). As far as I can tell, the following global objects need to be protected from simultaneous access from multiple threads: - tkmap - ktmap - void_caster_registry - iserializer_map - oserializer_map 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