Re: [boost] [Review] Shmem

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-02-10 18:10:07

Vote:
-----

I believe the library should be made part of Boost, definitely!

Usefulness:
-----------

There is great potential in this submission. I would not want to touch any system API for shared memory having this both easy-to-use and highly extensible framework. 
The library does not only provide access to shared memory, but also very useful machinery for general memory management. So I think it is (or at least should be) very useful to a wide audience.

 
Design / Documentation:
-----------------------

The library's name isn't excactly perfect. It's abbreviated, hard to pronounce and doesn't cover the whole functional range of the submission.

Maybe Boost should contain a memory subsection (just like it there is a "numeric" subsection and an "functional" subsection) and Boost.Pool would be another candidate --or better-- since the library provides enough memory management infrastructure that can be used with regular memory split Shmem (and maybe merge it with Pool to some degree) to form Boost.Memory.

I believe the library could generally benefit from a tighter Boost integration (of couse it's a wise choice to do this after it has been accepted). Probably it is possible to get rid of some of the duplication (more below).

Static member variables are local to a process -- is there an easy way to provide the semantics of a static member variable accross process boundaries (a static member that proxies a named object, perhabs)? If yes, it would be quite useful and should be added.

Many of the library's classes use "success results" for error handling (rather than throwing exceptions). I think it's OK for low-level stuff, as exception handling can be expensive luxury in some contexts, but it should be said in the documentation. Probably it's handy to have a wrapper/subclass that adds throw-exception-on-failure semantics.

The documentation states that the current STL implementations can't handle smart pointers through their allocators. It also mentions that VC7.1 is close. So what about VC8? And BTW. did you try to improve things by writing a bug reports to the developers of libstc++, STLport and maybe Dinkumware? Did you consider utilizing Boost.PtrContainer? 

shared_message_queue could use some templated overloads for the send and reveive functions to
- map pointers to offsets,
- submit values and arrays thereof as memory dumps, and
- provide optional type checking to compare sent and excepted type.
It would allow to easily manufacture complex serialized protocols.

A very useful data structure to have in shared memory context would be a discriminated union such as Boost.Variant.

There are no security attributes -- what are the defaults then? Can I emit machine code into shared memory and have another process jump into it? I'd like to (but might not be representative for the average user) -- it should be mentioned what the defaults are, though. Further, I can't really see how security attributes on memory segments relate to security attributes on files and why having them supported means so much work. Please tell me!

Documentation structure:
------------------------

The "Concepts and defininitions" part of the documentation seems misplaced to me (at this point of reading it doesn't help me a lot). Maybe it's something for the appendix.

I'd also like to see a few more links within the documentation.

The ownership pointers should be mentioned somewhere in the overview.

Implementation:
---------------

I don't like that 1-hack for the NULL values in offset_ptr and I don't understand why it's necessary. If NULL is outside the memory segment -- so what? NULL should never be dereferenced anyway... There should be a "just works" solution and there's no need for parametrization, here. Maybe I don't understand the problem correctly.

Evaluation effort, experience with the submission:
--------------------------------------------------

The evaluation is based on a good reading of the documentation and I haven't used the library yet but am certainly looking forward to it. In case I get to it during the review period I'll post an update.