[boost] [interprocess] Code uploaded to boost repository

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-06-12 14:08:43

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