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