fork()

Bernhard Herzog herzog at online.de
Mon Jun 7 19:53:18 CEST 1999


Arne Mueller <a.mueller at icrf.icnet.uk> writes:

> Hrvoje Niksic wrote:
> > 
> > Arne Mueller <a.mueller at icrf.icnet.uk> writes:
> > 
> > > All that woks fine now (after I spend a long time fiddling with the
> > > pipe and select stuff to synchronize I/O). However the forking is a
> > > waste of time and memory because all the children get their own
> > > large dictionary!
> > 
> > If you don't change the dictionary, the memory will not be copied.
> > Most modern Unixes support COW (copy on write) which means that the
> > actual fork()ing does surprisingly little.  Only when the memory is
> > written to, a new copy is spawned off.
> > 
> > If the children are modifying the dictionary, that's well something
> > different...
> 
> Huh, that's realy good news! But I don't understand how that works, when
> the child changes the dictionary it quickly gets it's own copy, so the
> operating system is watching the child's activity and copies memory when
> it's accessed for writing? However my children don't change anything in
> the dictionary ;-)

I fear that in reality the memory is copied after all. If they use the
dictionary in any way they are modifying refcounts of at least some of
the objects in the dictionary. From the OS's point of view this counts
as modifying the memory.

The same applies to all python objects that are referenced in the child
or the parent after the fork(). If I'm not mistaken this includes some
object categories that take a fair amount of your program's memory like
identifiers (represented by string objects) and function/code objects.

-- 
Bernhard Herzog	  | Sketch, a python based drawing program
herzog at online.de  | http://www.online.de/home/sketch/




More information about the Python-list mailing list