Geometry Boost List: Re: [geometry] Crash in rtree after growing shared memory, VS2012 x64, Boost 1.55

Subject: Re: [geometry] Crash in rtree after growing shared memory, VS2012 x64, Boost 1.55
From: Tim Finer (tim.finer_at_[hidden])
Date: 2014-11-25 21:37:25

Hi Adam,

On 11/25/14, 4:25 PM, Adam Wulkiewicz wrote:
> Hi Tim,
>
(edited)

> Of course you're right. The R-tree was designed to use persistent 
> storage, e.g. as an index in a database and this implementation should 
> certainly allow this.
>
> Boost.Interprocess allows to work around the lack of explicit 
> persistence but it's very raw/native mechanism. Its main purpose is to 
> allow sharing data between different processes. The memory is mapped 
> directly and AFAIU we shouldn't expect that this mapping will not 
> change in another version of Boost. What if some internals of 
> Interprocess are optimized and some additional data are stored in a 
> header of such shared memory?
>
> Do you expect to release new version of your program and bump used 
> Boost version so often that this is really a problem?
> I mean, your users would have to rebuild the tree only if needed.

All fair points.  I'm still thinking pretty hard about this.  We don't 
update often, but the troubles happen in both directions (users updating 
to new versions, users sharing files with older versions).

(edited)
> If you're asking about an info about the change of an internal 
> structure it isn't mentioned anywhere. There is only an info about 
> fixing a bug with Interprocess.
>
> I dissagree that this should be mentioned in the docs, it's an 
> internal change. Furthermore AFAIU Interprocess doesn't guarantee that 
> the representation of data will be the same in various versions of 
> Boost nor it wasn't designed to support versioning so we shouldn't 
> rely on this. Btw, Serialization supports versioning.
Sure, I understand that there are no guarantees between versions.  I 
might've misunderstood your warning though.  I thought you were advising 
not to use 1.55 IPC and bg rtree in general (without updating) because 
of an internal polymorphic node?  If so, then I don't see why the 
documentation with the sample shouldn't be edited to say something like 
"don't use this until 1.56" or something.

But if you were talking about files saved with 1.55 not working with 
1.56, then I agree there's no reason to document that.

>
>> As much as I like the performance of the bg rtree, I'll probably 
>> switch to an rtree implementation that has persistence as part of its 
>> design.  Boost isn't written so that different versions can easily be 
>> used by an application, so this doubly compounds the problem.
>
> Sure, everything that works for you. Thanks for your interest and 
> suggestions. Maybe some day it'll meet your needs.

Best,
Tim