You are not logged in.
Let me get this straight, when you fork() a child process this is what happens:
A copy of the parent isn't made just yet-- instead the child has read only rights to the actual parent's memory page. Once the child executes a write call the stack and heap pages are copied and marked with read and write rights.
Questions:
What happens to the shared memory segments? Is this section shared prior and post to the copy/RW escalation? How does the stack, heap and shared memory segments differ?
Last edited by Google (2010-08-25 16:01:17)
Offline
Not quite. In olden times, the entire address space of the child was copied, and the process could write to its memory without affecting the parent. This had enormous cost sometimes, which led to the variant vfork().
Now it's implemented using copy-on-write, which means that the memory itself isn't copied until the new child writes. Same observable behaviour, but vastly more efficient.
Offline
Isn't copy on write what I described with RO and after a write is issued by the child, it's copied and marked RW?
I understand it's done because the cost of copying an entire memory space could be huge.
The thing I don't understand is the difference between shared memory segments and the stack and heap. The stack and heap are implemented with copy on write but the shared memory segments are not? The textbook I use seems to state that.
Offline
Think of shared memory segments as their own entitites, truly separate from the process that created them. They aren't copied during fork() because they are not technically part of the process's address space.
A pointer to the shared memory segment may be copied if one exists before you fork, which would allow the child to access the segment created by the parent, but the segment itself is ... well it's shared
Offline
Ahh that's what I thought. I was confusing the shared memory segment with part of the stack and heap. Thanks!
Offline