Hi Ralph,

Continued.

>> Parallel programming with no
>> shared memory, i.e. by having processes only communicate with shared
>> memory, is much easier to program.
>>     

Another way to express what I'm saying is the following. You can run 
multiple processes in either separate or one memory space. When running 
in one memory space the following applies.

Sure you could have N threads - native or green - each running ONE 
(Squeak) Smalltalk process running in one protected memory space as long 
as NONE of these threads share ANY memory between them. That means no 
objects being shared. That means each Smalltalk process is really it's 
own image running independently with only one user level Smalltalk 
process. Any communication between them with objects is serialized and 
transmitted in some manner that - oh dear - avoids using shared memory 
or a shared communications "buffer" between two or more threads. This is 
done even though sending messages via shared memory buffers in one 
protected memory space is very efficient or sending messages via a 
shared memory space when more than one protected memory space is in use 
is also very efficient.

It seems to me that as soon as you have more than one Smalltalk process 
running in a Smalltalk image you will have concurrency control issues - 
unless the forked off threads are trivial in nature. This fact is the 
reason that I don't share your optimism about your solution - for if you 
have more than one thread in accessing the same memory space - 
regardless if they are in the same protected memory space or across 
operating system processes - you've got the concurrency complexity and 
program data consistency issues occurring. How do you avoid that?

Please educate me so that I fully understand your proposed solution. 
Thank you.

All the best,

peter