Hi Andrew,
Just in case I don't get a chance to do a formal review before the 16th, I have one brief comment.
I hope you can find to do a review, since it seems you have experience with memory mappings.
The mmaped_file class merges "a file which has some of its space mapped" with "a mapped portion of a file". While I realise that this is a shared memory library, not a general memory mapped file library, it might be useful to separate the two.
I'm open to develop a more advanced memory mapped file. I have no experience with memory mapping but if you want to help, I'm ready to put some effort.
The problem is that under the current design, mapping two separate parts of one file (a common task when trying to be clever with page-structured files) requires two file descriptors and two filename lookups. The other option is mapping a region which includes both parts, which wastes address space (occasionally to the point of it being impossible; consider mapping a 4Gb file on a 32-bit architecture).
If I understand this correctly, you want a class that can map more than a fragment of a file holding a single file descriptor, is that right? That would require that the memory mapped class should have a list of mappings (to unmap them in the destructor, for example). I think we should define about the interface you would want for this class. It can be implemented in a different class than current (simple) boost::shmem::mmapped_file. I don't have experience with this type of multi-mapped files but it's surely a good idea. Regards, Ion