From: Ron M <rm_rails@...>
Date: 2007-01-24T20:28:15+09:00
Subject: Re: Ruby for massively multi-core chips?

M. Edward (Ed) Borasky wrote:
> Uh ... be careful ... processes take up space in cache and in RAM.

I said process intentionally.

> only thing that would be sharable is the memory used for code ("text" in
> Linux terms). 

Nope.  Many (all?) OS's do copy-on-write. If one parent
forked the other children after a lot of initialization
was done, all that data initialized by the parent (including,
for example, loaded ruby modules, etc) would be shared too.

I think a lot of highly scalable servers (Oracle, Postgresql,
Apache 1.x, etc) use this approach.


Fundamentally the difference between threads and processes seems
to be the following.  With processes, most memory is unshared
unless you explicitly create a shared memory segment.  With
threads, most memory is shared unless you explicitly create
thread-local storage.   It's often easier to explicitly specify
the shared memory parts, since it makes you very aware of which
data structures need the special care of locking.  And since
the VM system will protect the private memory of processes
and AFAIK you'd have to go through some hoops to make the
OS enforce access to thread local storage, you'd be safer
with the multi-process model too.