site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Oct 7, 2009, at 10:32 AM, Jens Alfke <jens@mooseyard.com> 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... This email sent to site_archiver@lists.apple.com