Use relative pointers within shared-memory tables about speedtables HOT 3 OPEN

The use of absolute pointers allowed shared memory speedtables to be implemented without modifying all the speedtables code to support shared memory. Most of the code doesn't treat shared and private speedtables any differently. For one example, the only modification in the skiplist code was to pass the shared memory pool to the allocator, and change the order of some of the operations on skiplists to guarantee that the structures were always internally consistent without locking. I'm not even sure that guarantee will hold with relative pointers, since pointer indirection wouldn't be atomic any more.

from speedtables.

Agreed, this would be very difficult to achieve and would affect non-shared-memory speedtables performance negatively, about for sure. The atomicity issue Peter brought up could be solved with locks, but that could in a ginormous amount of locking.

I think with a 64-bit address space it wouldn't be difficult to map multiple shared memory speedtables to specific addresses in a non-conflicting way at the cost of a slight hassle. This will require multiple shared memory speedtables to actually work, which it doesn't currently, due to some static variables in ctables/shared/shared.c.

from speedtables.

Boost supports relative pointers in shared-memory regions using the offset_ptr template:
http://www.boost.org/doc/libs/1_51_0/doc/html/interprocess/offset_ptr.html

Although it still incurs a performance penalty, it might be worth investigating. The 64-bit address space does potentially mitigate the need for this, as long as an unused region of memory can be initially located.

from speedtables.