I have 3 processes communicating over named pipes: server, writer, reader. The basic idea is that the writer can store huge (~GB) binary blobs on the server, and the reader(s) can retrieve it. But instead of sending data on the named pipe, memory mapping is used.
The server creates an unnamed file-backed mapping with CreateFileMapping with PAGE_READWRITE protection, then duplicates the handle into the writer. After the writer has done its job, the handle is duplicated into any number of interested readers.
The writer maps the handle with MapViewOfFile in FILE_MAP_WRITE mode.
The reader maps the handle with MapViewOfFile in FILE_MAP_READ|FILE_MAP_COPY mode.
On the reader I want copy-on-write semantics, so as long the mapping is only read it is shared between all reader instances. But if a reader wants to write into it (eg. in-place parsing or image processing), the impacts should be limited to the modifying process with the least number of copied pages possible.
The problem
When the reader tries to write into the mapping it dies with segmentation fault as if FILE_MAP_COPY was not considered. What's wrong with the above described method? According to MSDN this should work...
We have the same mechanism implemented on linux as well (with mmap and fd passing in AF_UNIX ancillary buffers) and it works as expected.
FILE_MAP_COPYonly insteadFILE_MAP_READ|FILE_MAP_COPYFILE_MAP_COPY|FILE_MAP_WRITE? if you try this - can view that this combination of flags converted toPAGE_READWRITE. only singleFILE_MAP_COPYconverted toPAGE_WRITECOPY. as is. if want - test code pastebin.com/LkTj72CdFILE_MAP_COPYindeed solved the issue. And yeah, the documentation page is misleading (bitwise-OR comment) on this flag.