Re: [boost] [review] Shmem

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-02-15 11:57:14

Hi Dave,

  > 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.

Yes. The already suggested mmaped_file + mmapped_region is a good idea 
to optimize descriptor usage and to implement complex cache mechanisms. 
I will try to implement it for the final version.

> 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:

> 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.

The only problem I see to this behavior in my experience is that many 
times you develop a class for an embedded environment without exceptions 
(because of limitations) and you want to also test it in PC platforms or 
reuse use that code in another project and environment that do use 
exceptions. Since the code has not exception support (you don't program 
with exceptions AND error returns) you want the code to continue working 
in the new environment when the exceptions are thrown.

That's why I would prefer overloading the constructors with an 
additional std::nothrow parameter for no-exception environments to 
disable exception and use is_valid() approach instead of defining a 
macro. This code would still work in new environments when the code is 
used somewhere else where exceptions are enabled.

After the long debate about RAII I don't know if this solution would be 
accepted by boost members or only compile-time configuration is accepted.

> 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.

I see a need to define the official Boost time management functions for 
Thread/Processes. boost::xtime was supposed to be a temporary solution. 
Is Boost.DateTime the way to go? I think that it would be useful to 
decide it before Shmem is released.

Thanks for the review,

Ion