On Mar 24 13:52, Christopher Faylor wrote:
On Thu, Mar 24, 2011 at 06:40:36PM +0100, Corinna Vinschen wrote:
On Mar 24 12:44, Christopher Faylor wrote:
On Thu, Mar 24, 2011 at 10:23:57AM -0600, Eric Blake wrote:
On 03/24/2011 10:21 AM, Christopher Faylor wrote:
- In all three possible solutions above: What if the original file
handle used in the mmap call has been closed and the file permissions
have been changed in the meantime so that the process does not have
write permissions anymore?
- Isn't it going to be really slow? I guess if it only happens once
per page it won't be that bad but still: ouch.
There is a good chance that it's going to be slower. I'm not sure if
loading the file into the anonymous mapping is a problem since that
would have to be done under the hood as well, if the mapping is a file
mapping. For the first write to each page you have a hit of a couple of
cycles to change the page protection. When writing back the changes you
have to open the file, scan the pages and write back the changed ones.
Opening the handle could be quite a hit, writing the changes back would
be basically the same as the OS has to do as well. However, while the
OS can do so in the background whenever it sees fit, Cygwin couldn't.
And if I'm understanding correctly, it only needs to happen for the one
page at the end of the file; all earlier 64k chunks of the file can be
mapped normally, if you can guarantee that the normal mappings are
adjacent with the one special mapping.
Ah. So that would make it like a stack guard page then.
Uh, no. This is an anonymous mapping, ok? So there's no connection
to the file which has been mapped. So the mechanism would have to
cover the entire mapping. It would kind of having all pages set to
be guard pages, but you can't really use guard pages since they have
a hit for writing *and* reading.
Ok. So I had it right to begin with. This is like a guard page insofar
as you see an exception the first time you hit a page but it's not really
a "guard page" in any other sense.
Yep. A real guard page would not be very useful in this scenario.
The exception handler would have to restore the PAGE_GUARD protection
for every read access. That would really be an enormous hit.
I really hate that we have to go to such lengths to implement sensical
behavior.*
That's the question. Do we have to? I wrote my original mail to have
one potential solution to this problem in the records in the first
place. The other hope was that somebody has some better idea I just
don't see.
While the method I called the hard way is certainly implementable
somehow, I don't think it has any real chance. It's much to complicated
to get right. And then again, all this uproar for a border case
which is in theory not used by any sensible application? It's nice that
the autoconf test tests the POSIX requirement that the page reminder is
filled with 0 bytes, but, is that really necessary? What for?
And, is the autoconf test perhaps the only client for this solution
since no sensible application will read and write bytes beyond EOF? If
so, it's kind of sad that an autoconf test will result in lots of
application not using mmap, even though none of them actually uses the
map beyond EOF.
So, whatever we do in Cygwin's mmap, it's either rock or hard place,
as far as I can see