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