Re: [boost] [serialization]Boost.Serialization1.33.0BreaksSerializationCodeinDLLs

From: martin.ecker_at_[hidden]
Date: 2005-08-17 03:16:39

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: [phone]
Fax: [phone]
E-mail: martin.ecker_at_[hidden]
http://www.tab.at