Release 1.5.9 soon

Corinna Vinschen
Fri Mar 19 22:03:00 GMT 2004

On Mar 19 15:33, Nicholas Wourms wrote:
> vinschen wrote:
> >Not from me.  My new tape code is still twitching.  I have also two
> >funny new mmap features in the loop (only on NT), but that's not really
>                                         ^^^^^^^^^
> Hi Corinna,
> In partial response to this and the discussion you were having with 
> Alexandre Olivia regarding gcc-3.4 pch problems under cygwin.

You guessed it already, right?

I have it mostly working on NT.  But actually I'm not quite sure if it's
really worth the effort.

The 1st problem:  AllocationGranularity 64K.  The current implementation
fakes page aligned mapping by realigning address and offset plus playing
with page protection to mask the unused pages out.  I've a working patch
now which allows allocating mmaps beginning at real arbitrary page
boundaries using the AT_ROUND_TO_PAGE flag in calls to ZwMapViewOfSection.
Unfortunately the NT API has an annoying restriction:  That flag only
works for anonymous maps.  And it only works if an address is given in
the ZwMapViewOfSection call.  A NULL address will still always allocate
at granularity boundary.  The current solution always allocates 64K chunks
which allows to return consecutive pages.  To get it working similar using
AT_ROUND_TO_PAGE, a new trick has to be invented.  So what?
Since the current technique works pretty well, I'm not sure it's useful to
further follow that path.

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.

Given the drawbacks of both new "solutions", I'm a bit reluctant to put
this stuff into Cygwin at all.  The AT_EXTENDABLE_FILE seems to be more
interesting than the page alignment stuff but, anyway, it's yet another
extra code path for a questionable advantage.

Any opinions from others?

> It might be possible to overcome 9x's native memory mapping limitations 
> by supplying our own hooks to the 9x's system API. [...]
> Maybe it is of some use?  I could be wrong.

Personally I'm not interested in adding a lot of new code to get
something new running on 9x.  Let it die peacefully.  However, If
you feel confident that you can get it working nicely, feel free
to create a patch.  Serves NT right, if it eventually works better
on 9x than on NT.

> [*] If anyone's interested, I still have a copy of the last 9x DDK MS 
> distributed before they removed it for the newer NT-only versions.

I got it through MSDN but I never had a look into it so far.  Perhaps
that won't never change ;-)


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

More information about the Cygwin-developers mailing list