This is the mail archive of the cygwin-developers mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Broken autoconf mmap test

On 3/24/2011 2:24 PM, Corinna Vinschen wrote:
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

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

I do think it's worthwhile to examine the "why" before making changes here. If the main (only?) gain here is to appease autoconf, is there a way we can "cheat" at this? Getting autoconf'd packages to use mmap is a good thing but it does sound to me like it needs to be way easier for Cygwin to do this right, we need a specific work-around to target autoconf checks, or we shouldn't bother (for now).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]