site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=alastairs-place.net; h= subject:mime-version:content-type:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; q=dns/txt; s= aug07; bh=9M39QW7AqgjVv/0LSUGliCM46JA=; b=Pupy4aRoMxE6CvzbY4zdoo JxEWUBtNskC6jD+n6ZdOlCJwicdL64SihkPUxba+Z9hmHPKY0uj78o/FTPBzz6cK ROJlCn0b3pY+ERdwMueCxUK/af3qyKYvXUaz8oF/eJlPDJHZIwENeOAGAe19dz9i nXSzBe7Aa2P3BX2MXc3kY= On 21 Sep 2009, at 22:57, Brian Mastenbrook wrote: That clarifies things considerably... Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ 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... The problem is that code, the malloc heap, etc. are already placed in memory at that point. Using a zero-fill segment in an object reserves the heap space first, which forces the linker to move any relocatable code and the malloc heap to be allocated elsewhere. This is useful in general for image-based programming languages that are natively compiled, as you can save an image and then re-map it in memory as it was originally represented. I assume, given the above, that the motivation for this is that you're trying to set things up such that pointers in the shared memory all have the same addresses in each of the processes, and that means you want to reserve the same block of address space no matter what. So I guess the next question is why not move the shared memory segment further away from the heap's initial location? Or alternatively, why not use offsets rather than pointers within the shared segment (of course, there will be a performance hit, but offsets might result in safer code anyway), in which case you don't need to use MAP_FIXED? This email sent to site_archiver@lists.apple.com