martin.ecker@tab.at wrote:
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?
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. The problem is that when a DLL is unloaded, this table entry is deleted - as now the code to serialize this type is not available. The current code doesn't contemplate that the code so serialize a given type might reside in different DLLS. I believe that was my motivation for presuming that there would only be one. Changing the equal_to to value based rather than address based risks removing the "wrong" entry. This that would leave a vtable pointer is pointing to code that has since been unloaded. So this is still an open question as far as I'm concerned.
Unfortunately, I don't. The only "test case" we have is our entire system itself, which is a bit too big I'm afraid.
Well, you could write one using the tests in the library as a basis - its pretty easy - much easier than getting the test to pass on all the compilers!
Basically, it would be beneficial to add a DLL to the test suite and then write the following test cases: ...
When I have some time I want to do this. I also want to make a plug-in demo. This requires adding a little bit to extended_type_info to function as a class factory.
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. Robert Ramey