Re: [Boost-users] [Interprocess] How to Get Started?

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-06-19 12:03:56

> Thanks for your efforts! I think I can wait for a little while for the
> moment. Or... can I make use of the shmem docs in the sandbox instead?
> Any brief summary on the difference between that shmem version and the
> cvs interprocess version?

I suggest starting with Shmem, because Interprocess still needs a lot of 
work. This is a copy of the mail sent to the developers mailing list:

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

Hi to all,

   I've just uploaded Boost.Interprocess code to the repository so that
edgy Shmem users can start testing the library. Unfortunately, there is
no documentation and since I must change the focus from a shared
memory/memory mapped file library to a general interprocess
communication library and I think I should rewrite most of the
documentation. Please try the library only if you like the risk!

   Shmem users will notice name changes and lifetime changes. Now, all
named classes (except file locks) need an explicit
class_name::remove(name) function to remove the IPC mechanism from the
system, just like xxx_unlink in POSIX systems.

   Read-write mutex has been replaced with a more powerful
upgradable_mutex  and mutex classes have been simplified. Shared
memory/memory mapping has changed from Shmem to these new classes:

->file_mapping: A class that links a file with the address space of a
process, and allows creating several "mapped_regions" of a file.

//Link the file and the process's address space
file_mapping mapping ("filename", memory_mapping::rw_mode);

//Create several mapped regions of the file
mapped_region region1( mapping, 0/*offset*/
                       , 500 /*size*/, memory_mapping::rw_mode);

mapped_region region2( mapping, 500/*offset*/
                       , 1000 /*size*/, memory_mapping::r_mode);

->shared_memory_mapping: A class that allows creating, truncating,
opening links a shared memory object and links that with the address
space of a process. And allows creating several mapped_regions of the
shared memory object. Similar to file_mapping, but since with creation
capabilities. Another alternative would be to have shared memory stream
classes like shmstream, ishmstream, ioshmstrem so that shared memory is
created with these classes and shared_memory_mapping would loose
creation/opening capabilities and it would be very similar to
file_mapping. I've chosen the first alternative because creating new
stream classes was a lot of work. But this is not definitive.

->mapped_region: A class representing a memory region that comes from
any mapping (file, shared memory, in the future maybe a device...). Just
like UNIX mmap, mapped_region is independent from the back-end. It just
represents a memory region. Since a mapped region is independent from
the device, the user can mix memory mappings from shared memory and
files in a containers.

->mapped_file: A new version of Shmem's fully mapped file with atomic
initializations. Currently uses the old global mutex approach. I plan to
use file locks to avoid problems when a process crashes holding the lock
(the OS guarantees that the lock will be released).

->shared_memory: A new version of Shmem's shared_memory with atomic
initializations. It also uses the global lock for the moment.

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

The two-phase construction has been changed with throwing constructors,
I've added an experimental expand-in-place feature to allocator and vector.

I've added more test files. Please have a look at them until I write
some documentation. For the moment I have not updated library to bjam 2,
but I plan to this soon. There are Makefiles for linux and mingw and
solution files for VC7.1.

Comments, suggestions are welcome!

Regards,

Ion