This is the mail archive of the cygwin 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: 1.7.0 CVS mmap failure


On Jan 10 09:37, Brian Ford wrote:
> On Fri, 5 Jan 2007, Corinna Vinschen wrote:
> 
> > Actually this shows a problem in the mmap implementation with respect to
> > MEM_TOP_DOWN.  I think, what mmap should actually do is to create a
> > lightweight MAP_RESERVE anonymous mapping of the whole requested mapping
> > size, then close it again and then reopen it with the address it got
> > in this first try.  This would probably ensure that the subsequent two
> > mapping will work.
> 
> Why MAP_RESERVE if the requested mapping is NO_RESERVE?  This is just
> about whether you have swap (paging file) space initially committed or
> not, right?

MAP_RESERVE is Windows speak, NO_RESERVE is POSIX speak.  Using the same
term doesn't always mean the same.  The MSDN description of VirtualAlloc
is very helpful here.

> > This should work (knock on wood) on all systems now.  My testcases still
> > work on my 512 MB machine, so I'd appreciate if you could give the latest
> > snapshot a try on /3GB enabled machines.
> 
> Yes, this fixes my STC and the application from which it was derived.
> Thanks.

Glad to hear.

> > The 2nd problem: POSIX allows file mappings to exceed the file size,
> > Windows doesn't.  If the code tries to map a bigger size, the file on
> > disk is automatically extended to the size of the map.  The current
> > solution restricts the mapping always to the end of the file, so that it
> > isn't changed by the mapping size.  If the offset is beyond EOF, mmap
> > fails with ENXIO.  My patch uses the AT_EXTENDABLE_FILE flag in a call
> > to ZwMapViewOfSection which allows POSIX semantics.  But as you might
> > guess, this has again a downside.  First, it only works since W2K,
> > second and worse, it only works with PAGE_READWRITE mapping.  Neither
> > PAGE_READONLY, nor PAGE_WRITECOPY (aka MAP_PRIVATE) are allowed.  Oh
> > boy. While PAGE_READONLY can be managed by changing the page protection
> > afterwards, I don't see a way to get it right for MAP_PRIVATE.
> 
> So you mean that POSIX specifies that when a file is mapped larger
> than its size, as read only or private, the on disk file is actually
> extended?  That would have been completely contrary to what I'd expect
> from those two modes.  Otherwise, I don't understand this problem.

Read again.  It's the contrary, as you'd expected.  Briefly, POSIX allows
mappings beyond EOF w/o extending the file size, Windows doesn't.
There's a native NT flag called AT_EXTENDABLE_FILE which allows POSIX
semantics, but only starting with W2K, and only with PAGE_READWRITE, not
with PAGE_WRITECOPY page protection.  PAGE_WRITECOPY is basically what
POSIX calls MAP_PRIVATE, so the AT_EXTENDABLE_FILE flag works only 50/50.

> Also FYI:
> 
> You don't need more memory to enable /3GB on your machine.

Ok, thanks for the info.


Corinna


-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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