Hi, I have a few questions regarding mapped_region. 1. first of all, is mapped_region::flush() safe to use? on linux it is implemented as msync(MS_SYNC) which seems fine, but on windows it uses FlushViewOfFile alone, which IIUC does not flush the changes to disk. MSDN: "The FlushViewOfFile function [...] does not wait to return until the changes are flushed from the underlying hardware disk cache and physically written to disk. To flush all the dirty pages plus the metadata for the file and ensure that they are physically written to disk, call FlushViewOfFile and then call the FlushFileBuffers function." I'm not sure if they really mean "hardware disk cache", since no sync or flush function can entirely make sure of that. but FlushFileBuffers is documented to flush operating system buffers. and the quote above says a call to FlushFileBuffers is necessary. 2. can the mapped memory be accessed while another thread is calling flush()? does that affect the flushing? it is still required that all data that was written to the mapped region at the point of the flush() call is written to disk when it returns. Interprocess' documentation doesn't say anything about that and I can't seem to find any information about that on the underlying functions mmap/FlushViewOfFile either. and 3, not entirely boost related: I get some strange performance results using mapped_region::flush() on linux (not tested on windows so far). I already reduced the flush() calls to a minimum but I still get better performance in many cases using my own filebuf implementation that performs paging without hardware support, using a std::filebuf. using std::filebuf shouldn't be faster than hardware file mapping. when I call flush() relatively frequently that in itself drives performance down, but when I call it less frequently it blocks for noticeable amounts of time. (thus, question 2) do the offset/size arguments to mapped_region::flush() affect performance? I could track what pages are changed, but I was under the assumption the OS already does that. Thanks