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