On Sun, Jan 17, 2010 at 3:22 PM, vicente.botet <vicente.botet@wanadoo.fr> 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.