This is the mail archive of the
mailing list for the Cygwin project.
Re: Atomic mmap replacement
On 02/19/2018 12:19, Corinna Vinschen wrote:
I work on an app that does something like this (but for other reasons,
and it'll never be ported to Cygwin).
On second thought, we *could* do this, if the pages have been mmapped
before(*). Unfortunately this would require a *major* revamp of the
page handling in mmap. We would have to keep the mapping of every
single 64K page separate.
I.e., requesting a file mapping of 256K at offset 0 on the POSIX level
would have to be handled as four Windows file mappings under the hood:
1. a 64K file mapping at offset 0
2. a 64K file mapping at offset 65536
3. a 64K file mapping at offset 131072
4. a 64K file mapping at offset 196608
A request to mmap another 64K page to the third mapping in this example
could then be done by unmapping the third mapping and replace it with
the requested mapping.
I'm not sure this is feasible. It would complicate and slow down the
code especially for big mappings; one call to NtCreateSection and one to
NtMapViewOfSection per 64K page, plus the overhead of making sure that
all mappings are in the right, sequential order in memory. Plus the
overhead of having to remap a lot more mappings in forked children. The
"Cygwin is slow" meme would get another interesting facet :}
I'm also dubious, but I'll point out that it'd probably be reasonable to
do this only on regions that are mapped PROT_NONE initially, other
regions could work as they do now. That'd help performance in the
common case. Also, if Windows has a way to prevent use of a region
other than creating a mapping, Cygwin could perhaps emulate PROT_NONE
mappings without actually creating a mapping (at the cost of even more
code complexity, probably).
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple