Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28641 > unrolled thread

Re: Looking for an IPC solution

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Looking for an IPC solution Dave Angel <d@davea.name> - 2012-09-06 16:54 -0400
    Re: Looking for an IPC solution Ramchandra Apte <maniandram01@gmail.com> - 2012-09-08 08:11 -0700
      Re: Looking for an IPC solution Andrew Cooper <amc96@cam.ac.uk> - 2012-09-09 20:14 +0100
    Re: Looking for an IPC solution Ramchandra Apte <maniandram01@gmail.com> - 2012-09-08 08:11 -0700

#28641 — Re: Looking for an IPC solution

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

[toc] | [next] | [standalone]

#28724

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

[toc] | [prev] | [next] | [standalone]

#28794

On 08/09/2012 16:11, Ramchandra Apte wrote:
> 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
> 

No - pages are always 4k (or bigger given superpage support).

You are probably thinking about the granularity bit in descriptor
entries, which is relevant for segmentation.  The granularity bit
changes the limit between 1 byte or 4K chunks, as there are only 20 bits
of limit space in a 32bit {L,G}DT entry.

However, in the modern days of paging, segmentation support is only for
legacy compatibility.

~Andrew

[toc] | [prev] | [next] | [standalone]

#28725

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web