Re: [boost] [serialization] Boost.Serialization1.33.0BreaksSerializationCode inDLLs

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-16 10:45:56

martin.ecker_at_[hidden] 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