fork()

[Stephan Houben]

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

> Hrvoje Niksic wrote:
> > 
> > Bernhard Herzog <herzog at online.de> writes:
> > 
> > > 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.
> > 
> > Eek.  You're right.  Refcounting truly sucks.  :-(
> 
> Hm, that means as long as I realy don't look at the data of the parent
> the data is shared between parent and child. Thats funny - it's a
> useless feature. As soon as a child reference that dictionary  it gets
> it's own copy. 

It's still not completely useless; you don't have to explicitely say
which memory pages will be copied. 

> What about shared memory, is it possible to put objects into a shared
> memory segment, most advanced language can do that?

Don't know if anyone wrote a Python wrapper around the POSIX shared memory
stuff. However, you probably don't want/need to do that. The reason is
that there's basically no (portable) way to get malloc() to allocate
new objects in the shared memory, so you can't create Python objects
in the shared memory. So you can probably only access the shared 
memory as a special array a la the "array" module.

In which case this buys you little, since if you stored the data in
an "array" module array, the data would be shared automagically.
So that's the approach I recommend:

1. Build your shared data, painfully, in one or more "raw" arrays as provided
   by the "array" module.
2. Don't change your arrays after that.
3. Do the fork and access the arrays from all the child processes.

This should work. (I think)

Greetings,

Stephan