Note that there are some explanatory texts on larger screens.

plurals
  1. POUnderstanding file mapping
    primarykey
    data
    text
    <p>I try to understand mmap and got the following link to read:<br> <a href="http://duartes.org/gustavo/blog/post/page-cache-the-affair-between-memory-and-files" rel="nofollow">http://duartes.org/gustavo/blog/post/page-cache-the-affair-between-memory-and-files</a></p> <p>I understand the text in general and it makes sense to me. But at the end is a paragraph, which I don't really understand or it doesn't fit to my understanding.</p> <blockquote> <p>The read-only page table entries shown above do not mean the mapping is read only, they’re merely a kernel trick to share physical memory until the last possible moment. You can see how ‘private’ is a bit of a misnomer until you remember it only applies to updates. A consequence of this design is that a virtual page that maps a file privately sees changes done to the file by other programs <em>as long as the page has only been read from</em>. Once copy-on-write is done, changes by others are no longer seen. This behavior is not guaranteed by the kernel, but it’s what you get in x86 and makes sense from an API perspective. By contrast, a shared mapping is simply mapped onto the page cache and that’s it. Updates are visible to other processes and end up in the disk. Finally, if the mapping above were read-only, page faults would trigger a segmentation fault instead of copy on write.</p> </blockquote> <p>The folloing to lines doesn't match for me. I see no sense. </p> <blockquote> <p>A consequence of this design is that a virtual page that maps a file privately sees changes done to the file by other programs <em>as long as the page has only been read from</em>.</p> </blockquote> <p>It is private. So it can't see changes by others!</p> <blockquote> <p>Finally, if the mapping above were read-only, page faults would trigger a segmentation fault instead of copy on write.</p> </blockquote> <p>Don't know what the author means with this. Is their a flag "MAP_READ_ONLY"? Until a write occurs, every pointer from the programs virtual-pages to the page-table-entries in the page-cache is <em>read-only</em>.</p> <p>Can you help me to understand this two lines? Thanks</p> <p><strong>Update</strong><br> It seems it got it, with some help.</p> <blockquote> <p>A consequence of this design is that a virtual page that maps a file privately sees changes done to the file by other programs as long as the page has only been read from.</p> </blockquote> <p>Although a mapping is private, the virtual page really can see the changes by others, until it modifiy itselfs a page. The modification becomes <strong>is private</strong> and is only visible to the virtual page of the writing program.</p> <blockquote> <p>Finally, if the mapping above were read-only, page faults would trigger a segmentation fault instead of copy on write.</p> </blockquote> <p>I'm told that pages itself can also have permissions (read/write/execute).</p> <p>Tell me if I'm wrong.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload