Re: [boost] Boost library submission (poll for interest)(2)

Subject: Re: [boost] Boost library submission (poll for interest)(2)
From: strasser_at_[hidden]
Date: 2010-01-17 16:47:37

Zitat von Bob Walters <bob.s.walters_at_[hidden]>:

>
>> If I have understood, the data is stored using Boost.Interprocess.  
>> Could you clarify why do you force the stored types to be  
>> Serializable?
>
> I'm not relying on the durability of the boost interprocess region.
> Nor am I trying to serialize the shared memory from directly to disk.
> Stefan has challenged me to do that

I didn´t realize ;)

> , and I'm considering a variation
> which would do that, but it isn't without it's own issues.  For now, I
> went with the approach of using serialization for sending K,V types to
> logs or checkpoints as a way to avoid those issues.
> My current concern with direct storage is that (assuming K and V may not
> be concrete types) it seems like it will require a lot of memory use
> tracking which could add an unwanted expense to shared memory  
> pointer traversal.

if you keep using serialization we should also think about unifying  
this aspect of our libraries. as we've discussed before I have some  
ADL functions that avoid boost.serialization if possible.

they
1. use std::memcpy() if serialization::is_bitwise_serializable<> yields true
2. use user-supplied functions, described here:
https://svn.boost.org/svn/boost/sandbox/persistent/libs/persistent/doc/html/persistent/advanced.html#persistent.advanced.optmem
3. only if 1 and 2 fails, invokes Boost.Serialization.

so for a trans_map<int,int> for example, there would be no  
overhead(besides memcpy) and no calls to Boost.Serialization (and no  
compile-time instantiations!)