Re: Using mmap to extend an existing mapping?
Re: Using mmap to extend an existing mapping?
- Subject: Re: Using mmap to extend an existing mapping?
- From: Terry Lambert <email@hidden>
- Date: Wed, 07 Oct 2009 11:12:15 -0700
On Oct 7, 2009, at 10:32 AM, Jens Alfke <email@hidden> wrote:
I'm calling mmap to create a new mapping of a file. Later on I
append data to the file (just using regular write calls) and then I
want to map in the new data. If possible I want to grow the existing
mapping in place, to avoid invalidating all the existing pointers.
Based on the mmap(2) man page, it sounded as though I could do this
by passing in the base address of the old mapping and the MAP_FIXED
flag; and it would replace the mapping with a larger one if
possible, or return MAP_FAILED if there wasn't room.
::mmap(_start, newLength, PROT_READ, MAP_SHARED | MAP_FIXED, _fd,
_position);
Instead, what I see happening (by running vmmap(1) before and after
the call) is that the mmap call blows away any other following VM
regions to make room for my request. Since these regions are often
things like stacks, object code or malloc heaps, this is immediately
fatal. :-(
Is there any way to get the behavior I want, where mmap will extend
the mapping but will fail rather than deleting any other mappings?
Generally no. These are required semantics according to both
historical behaviour and the standards, both of which assume the
programmer knows better than the API.
Typically you are expected to keep your mapped regions away from stack
and heap allocations, which means either limiting yourself to a
fraction of the address space and using a generally unused region, or
by establishing your mapping followed immediately by an adjacent
mapping of zero-fill pages that you can later choose to map over top
of (and generally it's a good idea to map these pages initially as no
read or write to have them serve a dual function as guard pages).
There are Mach APIs that would let you check for collisions, but I'm
not sure that the check and allocation if not taken can be made atomic
for a multithreaded application.
You could potentially request an mmap() flag/option to enforce this in
some later Mac OS X major release by filing an enhancement request bug
report, but if there is no way to do it in the underlying Mach APIs...
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden