allow read into untouched noreserve mappings

Brian Ford
Wed Jul 19 15:12:00 GMT 2006

On Tue, 18 Jul 2006, Corinna Vinschen wrote:

> On Jul 18 11:59, Brian Ford wrote:
> > I confess to not understanding the purpose and inner workings of either
> > search_record implementation.  I first tried the two parameter version,
> > but then realized it was searching through file offsets rather than map
> > addresses (what is that usefull for?).
> The answer is in list::try_map.  It tries to find a suitable, unused
> record which can be reused for another mapping.  The idea here is to
> accomodate old, non-standard implementations which assume that two
> consecutive mappings are using consecutive pages in memory.  An example
> are old autoconf tests.  This was more of a problem when getpagesize()
> was 4K.  Today it will only be used on 9x due to the alignment bug I'm
> referring to in mmap64.

Thanks for the constructive information; it is greatly appreciated.  I
don't totally understand it yet, but I'll study it.

> > On Tue, 18 Jul 2006, Corinna Vinschen wrote:
> > > Don't be surprised that I now used getpagesize() instead of
> > > getsystempagesize ().  [...]
> >
> > I know this dichotomy has been discussed at length before and there
> > doesn't seem to be any win-win compromise.  I'm not sure if I agree or not
> > *shrug*, but my opinion doesn't matter much anyway.
> You know the problem of page size vs. allocation granularity, right?
> I was fighting for keeping the page size in Cygwin at 4K for a long time
> but at one point it got just too awkward to support it any longer,
> so I gave up.  There's really no reason to go through this once again.

Yes, exactly.  I was trying to acknowledge that.

I was thinking this was just an internal detail of an extension that
was trying to minimize swap usage and therefor smaller with more faults
was better.  After sleeping on it, I'm even less sure of that stance now.

> > One minor nit though, this stuff could be moved after the check for an
> > empty mmap region list.
> Indeed.  But, hey, this is the cygwin-patches list.  Just provide a
> patch!

I wasn't sure that minor nits and code rearrangements would be accepted as
patches, or would just be considered insulting.  If the former, I would be
happy to submit patches that IMHO make the code more readable as I try to
understand it myself.  (Things like assignments inside conditionals and
repeated function calls, even if they are inlined, make it harder for me
to see what's going on.)

> > I guess it'll be a while then before this hits a release then :-(.  Thanks
> > for applying anyway.
> Sure.  The branch will be folded back into the main line after 1.5.21
> has been released which will be very soon.

Great, thanks!  And now back to patches only :-).

If anyone would like to reply off list, that would be fine with me.

Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...

More information about the Cygwin-patches mailing list