[boost] Re: Boost Shmem-Shared memory library first archive available

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2004-11-22 17:00:54

"Ion Gaztañaga" wrote:

> first rough version of shared memory library 
> http://groups.yahoo.com/group/boost/files/boost.shmem.zip

________________________________________________
1. The HTML documentation does't allow
   to change font in browser.
________________________________________________
2. End of document can be marked so it doesn't
   look like cut in half during transmission.
________________________________________________
3. docs 3.2:

"Boost Shmem provides some STL containers"

probably means

"Boost Shmem provides some STL compliant containers"
________________________________________________
4. Example in 3.2: the "alignement" parameter in
   segment.create() isn't found in code.

________________________________________________
5. Example in 4.2:

   segment.named_new<MyType>
      ("MyType instance",  /*name of the object*/
       10                  /*number of elements*/,
       false  /*if previously present, return error*/,
       0      /*ctor first argument*/,
       0      /*ctor second argument*/);

a. What does t mean "return error" here? Exception?
b. Wouldn't it be better to split the function into
   two, one which allow to overwrite, second which
   doesn't.
   This would get rid of boolean parameter which
   is always hard to understand w/o context.
c. Could the syntax be like:

    segment.named_new<MyType>("name")(ctor_param1, ....);

   so it looks more like operator new?
   Current signature feels very prone to bugs.

In:
   std::pair< MyType *, std::size_t> res =
      segment.find_named_new< MyType > ("MyType instance");

Why do I need the "size"? Doesn't a type have
always the same size regardless? Isn't
  sizeof(MyType) == res.second
always?

________________________________________________
6. Could you use namespace shmem_detail or so
   instead of "detal" to avoid possible clashes?

________________________________________________
7. exceptions.hpp:

a) file name should be shmem_exceptions.hpp or so

b) does it make sense to have common base
   for both exceptions there?

________________________________________________
8. offset_ptr.hpp: full_offset_ptr class

a) using char as de-facto bool class has usually
   no practical advantage and may be actually slowe.

b) The flag could be eliminated completely.
   If m_offset == 0 it is NULL pointer and
   no data allocated in shmem will starts
   on the beginning. This would also eliminate
   need for min_offset_ptr.

c) swap() could be added and other operators.

________________________________________________
9. Maybe the protection of mutext from shared ptr
   lib could be worked around so the code
   duplication would be eliminated. Even if it
   is dirty it would be worth.

________________________________________________
10. The example in 4.3 uses very dirty C-like
    approach with casts. Cannot it be rewritten
    in C++ way with overloaded new?

________________________________________________
11. Some source files use Unix line ends,
    some DOS line ends. Just bit strange.

________________________________________________
12. The simple algorithm to find fitting memory
    block may not be adequate for high-performance
    apps (who are most likely to use shared
    memory).

________________________________________________
13. Can be be possible to identify named objects
    with something else than C string? Say
    wchar_t* or numeral or other templated type?

________________________________________________
14. What I would like to see:

a) avoiding shmem specific containers/mutexes/etc
   as much as possible.

b) ability to "equalize" shared memory features
   between  operating systems. E.g. Windows
   deletes shared memory when no one is using it,
   Unix keeps it until destroyed explicitly.
   I would like to have both approaches on
   both platforms (handled possibly by exec()ing
   helper process.

   In addition, Shmem should provide platform
   specific access to its internals,
   e.g. to Win32 handles to allow security settings.

c) support for inheritance in shmem using object
   factories, e.g. like one in Classloader
   http://s11n.net/papers/classloading_cpp.html

d) support for "transactions": I would like to
   be able to add/modify/remove objects in shared
   memory and made all changes visible to other
   process in one moment. This would save me
   one more IPC channel to signal readiness of data.

   If possible the library should provide several
   levels of isolation. Long lasting
   transactions could be also considered.

/Pavel