Looking for an IPC solution
Ramchandra Apte
maniandram01 at gmail.com
Sat Sep 8 11:11:48 EDT 2012
On Friday, 7 September 2012 02:25:15 UTC+5:30, Dave Angel wrote:
> 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
>From my OS development experience, there are two sizes of pages - 4K and 1 byte
More information about the Python-list
mailing list