On Jul 30, 2011, at 11:39 PM, vincent habchi wrote: >> Memory is "virtual", the addresses you appear to be working with are not >> real (i.e. they don't refer to the real address of the physical RAM >> underneath). Instead, a bit of hardware translates these to the real >> addresses as needed at some level far below the perception of your program. >> You cannot access the virtual address space of any other process other than >> your own. > > That is, of course, not true. When a process forks, the child and the parent, > though being two separate processes, still share the same virtual memory map > (at least until the child calls exec (3)). And you can arrange to share pages > of memory in different processes via, e.g, shmat (2), at the Unix level. > That's how most databases (e.g. PostGreSQL) work, inter alia.
You're quibbling, and not exactly with exactitude. When a process forks, the child and parent get different virtual memory maps that, for the time being, happen to point to the same physical memory pages. The sharing is an implementation detail, for optimization. Conceptually, the parent's memory is copied into the child's memory space, so that if one of the processes modifies the "shared" memory, the other process does not see the change. The implementation, under the hood, does copy-on-write so that the cost of that copying can be deferred until needed. Since fork is usually followed by exec in the child, the copying usually never takes place, so it's a particularly good optimization. Don't be misled into thinking that just because the copying is deferred that the parent and child are actually sharing a single virtual memory space. The other methods you mention of sharing memory are by special arrangement, and rarely used (although extremely useful when they are). The point vincent was making was to correct the OP's belief that a random pointer (0x18c95b0 was the example mentioned) pointed to some memory somewhere, and that the EXC_BAD_ACCESS exception was raised if that memory happened to belong to some other process. The truth is, each process has its own virtual memory map, and 0x18c95b0 may point to different physical addresses, or to nowhere, depending on which of those memory maps you look it up in. But a process does not have the opportunity to try looking it up in any map but its own. The exception is raised if the current process' memory map doesn't map it to anywhere. (It could also be raised if the pointer is being looked up for write access, but the current memory map maps it to a read-only location.) That is, it's not "look up the address, and see who it belongs to" but "look up the address in my space, and see if it exists there". _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
