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

Subject: Re: [boost] Boost library submission (poll for interest)
From: Bob Walters (bob.s.walters_at_[hidden])
Date: 2010-01-19 00:30:38

On Sun, Jan 17, 2010 at 3:22 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:

>> I'm not relying on the durability of the boost interprocess region.
>
> Why? What are the main problems with this approach?

I haven't figured out how to do it yet without having something similar
to the Boost.Persistence locator construct to represent a pointer in
shared memory, and permit the tracking of modifications made to portions
of non-concrete key/value pairs.  There is an overhead to that approach
which seems unavoidable.  Otherwise the approach requires that all changes
to the shared memory region data are postponed until those changes
are first determined and written to the log in order to ensure recoverability.
Ultimately, another implementation of map is required.

When I started STLdb, I chose to dodge these issues in favor of
writing serlaized
forms of key/value types, and permitting direct use of shared memory for
storing some transaction-local storage.  The later helps with some aspects of
my concurrency model, but also meant the region can't be recoverable.

>> Nor am I trying to serialize the shared memory from directly to disk.
>> Stefan has challenged me to do that, and I'm considering a variation
>> which would do that, but it isn't without it's own issues.
>
> Could you develop?

I am working on this in my spare time, and can't commit to any timeframe.

However, in the course of working on a unified transactional layer, if
it becomes possible to share
some of the Boost.Persistent optimizations which eliminate the need
for Serialization of objects
in the case of concrete types, I should be able to use those, and that
would at least minimize the
difference between what exists and the ideal.

> I don't understand what K and V are? (Key, Value?)

Yes.