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