Re: [boost] [Review] Shmem

From: Andy Little (andy_at_[hidden])
Date: 2006-02-12 05:33:50

My review is based on a very light skim through everything. Sorry its not more
comprehensive, but if/when I get time I defintely want to play with this
library!

***Design***

Shmem is limited in scope. Its a low level building block for implementing local
inter process Object transfer.  AFAICS shmem doesnt concern itself much with the
protocols of IPC. It wont scale to distributed communications. Is there scope
for proprietary IPC mechanisms , (such as COM, DDE, and CORBA), to be built on
top of it ?

The restrictions placed on the types of objects that can be placed in shared
memory are understandable, but heavy and presumably cant be checked?. Now there
Must be a special definition of an shareable-object outside C++ class eg like a
COM interface. In fact some evidence that this is occurring with classes such as
basic_named_shared_object. However should these objects not be designed for
distributed environment as well as local one? If shmem doesnt provide protocols
for building objects that can be passed over a network and in a scaleable way
then objects using its mechanisms direct will be of limited use, so larger
picture should be taken into account Now.

*** Offset Pointers ***

Couldnt pointer_offsets be a class?. This would mean overloadable functions,
type safety, rather than ptrdiff_t which I'm guessing is an int or something?

--------------

***Did you try to use, with what compiler?***

Tested out ProcessA/ProcessB example in VC7.1. Could do with some documentation
as to how it should work. C++ IPC is unfamiliar territory! Eventually figured
out that running ProcessA and then ProcessB in separate Command Prompt windows
should have the desired effect.. which it did. Its Fun.!

----------

*Documentation*

It seems a lot of effort has been put into documentation. Its noted that Ion is
not a native English speaker, but it reads OK in spite of that.  It probably
needs to be better organised though. Concepts and Definitions section should be
split into Concepts section and Definitions section. Traditionally definitions
are put near to start of docs so user knows where they are before defined words
are used. Definitions should be expanded A Lot ... to include many more entities
such as mutex, semaphore, shared-memory, named-shared-memory,offset-pointer,
process  etc etc etc.  Even if you think you know what they mean, some words
need to be defined so reader can see what author means in this particular
context. Quick guide for the impatient could then benefit from having unfamiliar
terms hyperlinked to their definitions.
----------

**Construction ***

On construction issue , only because its been brought to light recently.

    named_shared_object segment;
    //Create shared memory
    if(!segment.open_or_create(shMemName, memsize)){
    std::cout << "error creating shared memory\n";
    return -1;

could (presumably?) be replaced with

    try{
        //Create shared memory
        named_shared_object segment(shMemName, memsize);
    }
    catch( shmem_exception & e){
        std::cout << "error creating shared memory\n";
        return -1;
    }

which I would prefer.

---------------------

***Should it be a boost library**

You betcha. Yes indeed It should definitely be a boost library. C++ needs this
type of library badly. It is all very low level however and I would like to see
a higher level abstraction for designing objects that can be passed about over a
network too though and shmem objects should then try to conform to that, but
that shmems role would be maybe as a building block for that. Needs to be
discussed. If it is in Docs.. Sorry I missed it!

regards
Andy Little