Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #28725
| Newsgroups | comp.lang.python |
|---|---|
| Date | 2012-09-08 08:11 -0700 |
| References | <50410AD6.7080003@shopzeus.com> <loom.20120831T230411-646@post.gmane.org> <k29q3g$90m$1@ger.gmane.org> <2p0i489b5kq6ad2kc70r82ksjqpcatdsqu@invalid.netcom.com> <mailman.328.1346964870.27098.python-list@python.org> |
| Subject | Re: Looking for an IPC solution |
| From | Ramchandra Apte <maniandram01@gmail.com> |
| Message-ID | <mailman.383.1347117117.27098.python-list@python.org> (permalink) |
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
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
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
csiph-web