[bind10-dev] shared memory data source: file-based (mmap) vs memory-only

[JINMEI Tatuya / 神明達哉]

Before detailing the feature and breaking it into development tasks,
I have two big questions to discuss.  This is one of them.

There are roughly two choices:
1. use a file (or files) containing the memory image and map it to the
   memory
2. build everything in-memory

In either case, I believe we'll use the Boost managed memory segment
classes; otherwise allocation/deallocation or incremental growing the
region will be a nightmare.  Specific corresponding these classes are:

1. managed_mapped_file: http://www.boost.org/doc/libs/1_53_0/doc/html/interprocess/managed_memory_segments.html#interprocess.managed_memory_segments.managed_mapped_files
2. managed_shared_memory: http://www.boost.org/doc/libs/1_53_0/doc/html/interprocess/managed_memory_segments.html#interprocess.managed_memory_segments.managed_shared_memory

(btw since we'll use the Boost abstraction low-level keywords like
mmap(2) or System V shmem don't make much sense.  So I avoided using
these terms above).

As far as I can see and based on my quick experiments, both classes
will meet our minimal need.  The major difference is the use of
concrete files.

I personally prefer the file-based approach, because this can work as
a persistent on-disk copy that enables nearly-zero (hot start case) or
a few-to-10-ish seconds (cold start case, with some initial work) of
start up time.  The major disadvantage is management overhead of the
files and the risk of having corrupt on-disk images.

Do others have opinions/preferences on this?

On a related note: I remember there was a mention of the use of
copy-on-write when updating the current version of the shared memory
image.  As far as I can see, we can't benefit from it, at least not if
we use the above Boost utility classes.  We'll first need to make a
complete copy of the current image, either on disk or in-memory and
then updated the copied version.

---
JINMEI, Tatuya