From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-16 10:45:56
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk