[boost] [review] Shmem

From: Dave Moore (jdmoore99_at_[hidden])
Date: 2006-02-15 05:34:26

I recommend that Shmem be accepted into Boost.   Most of my comments below
have already been raised by other posters, so I'll just mention which I
agree with.   I would use Shmem today if it were available in its final form
in Boost.

- What is your evaluation of the design?

I was impressed with the breadth and depth of the design.  It thoroughly
covers this domain.

My only suggestion for the design would be to separate the concept of
mmapped_file from that of the mapped region. The mmapped_file class should
just be concerned with managing the "backing store", whether that is an
ordinary file, /dev/zero, or the Windows swap file.   The mmapped_region is
responsible for mapping a portion (or all) of the mmapped_file into the
process's memory space, and you could have multiple mmapped_regions per
mmapped_file.

The current implementation could be covered with a convenience class/factory
that creates a mmapped_region that maps an entire mmapped_file.

- What is your evaluation of the implementation?

Overall, quite impressed.

I am in strong agreement with the "RAII crowd" in that I do not want to see
two phase initialization.  To summarize which of the sub-arguments I agree
with, or find to be important:

1.  I would like to see constructors that throw when they cannot construct
the object.
2.  I see no compelling need for fstream() equivalent "empty" constructors
3.  I do agree that "reopen()" is a useful concept, and that it could also
throw.
4.  For embedded environments that cannot use exceptions, I suggest using
boost::config to disable the throwing() behavior, and provide an
"isValid/isOpen" accessor function which would allow embedded developers to
interrogate the state of the object.  When exceptions are turned on, this
function would always return true.

Re: Boost::Threads and synchronization primitives I agree that Shmem
provides (yet another) compelling case for factoring Boost::Threads into
synchronization primitives and higher level thread management objects
(threads, pools, thread specific storage, etc.).  The synchronization
primitives are too useful as separate objects.

- What is your evaluation of the documentation?

I actually thought it was adequate, if a little rough around the edges.  I'm
familiar with the problem domain, though.

- What is your evaluation of the potential usefulness of the library?

Having a comprehensive, cross-platform library for shared memory is hugely
useful.

- Did you try to use the library? With what compiler? Did you have any
problems?

I evaluated this library using VC 7.1 and VC 8.0 without problems.

- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

I put a moderate amount of effort into this evaluation.  I read the
documentation and looked in depth at the file mapping and allocator
objects.

- Are you knowledgeable about the problem domain?

Yes, I've used shared memory objects and synchronization extensively in
financial and research application development.

Regards,
Dave Moore