Looking for an IPC solution

[Dave Angel]

On 09/06/2012 04:33 PM, Dennis Lee Bieber wrote:
> <snip>

> Note that this difference mainly applies to how the processes are
> themselves are created... How the library wraps shared data is
> possibly different (I've never understood how a "fork" process can
> avoid memory conflicts if it has write access to common virtual memory
> blocks).
Here's an approximate description of fork, at least for the memory
aspects.   During a fork, the virtual memory table is copied (that's
descriptors for all mapped and allocated memory) but the memory itself
is NOT.  All the new descriptors are labeled "COW"  (copy-on-write).  As
that process executes, the first time it writes in a particular memory
block, the OS gets a memory fault, which it fixes by allocating a block
of the same size, copying the memory block to the new one, and labeling
it read/write. Subsequent accesses to the same block are normal, with no
trace of the fork remaining.

Now, there are lots of details that this blurs over, but it turns out
that many times the new process doesn't change very much.  For example,
all the mappings to the executable and to shared libraries are
theoretically readonly.  In fact, they might have also been labeled COW
even for the initial execution of the program.  Another place that's
blurry is just what the resolution of this table actually is.  There are
at least two levels of tables.  The smallest increment on the Pentium
family is 4k.


-- 

DaveA