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