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 -- http://mail.python.org/mailman/listinfo/python-list
