I'm sure I'm going to regret saying anything in this thread but what the hell...
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.
I don't think that was actually specified but yes that would be one way of doing it.
That means no objects being shared.
No it doesn't. Objects can be shared via communication; that's what messages are for. It only happens that the Smalltalk systems we're mostly used to share by sharing memory.
That means each Smalltalk process is really it's own image running independently with only one user level Smalltalk process.
Works for me. Like an ecology of cells. Now where did I hear that analogy before? Oh, yes, I think it might have been either Alan Kay's doctoral thesis or an early talk on the idea of objects.
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.
Transputer.
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.
Only applies in the limited sphere of the typical single processor systems we have got used to over the last few years. And for the purposes of any discussion about real parallelism, current 2/4/8 core systems are really a poor quality patch on the single cpu idea.
A key idea that people are going to have to get used to is, oddly enough, just like the one they had to get used to in order to accept late binding and dynamic languages. That is, to paraphrase a old quotation from Dan Ingalls (I'm pretty certain) "we've got past the stage of worrying about the number of computational cycles. we need to start worrying about the quality" Nominal inefficiency in having message passing across processes done by something 'slower' than shared memory may be a key to allowing massively spread computation. Trading the 'efficiency' of hand coded assembler for higher level languages made it more practical to build bigger programs that could do more. Trading the 'efficiency' of C for a decent late bound language allows more conceptually complex problems to be tackled. Trading the 'efficiency' of shared memory as a medium for sharing information with some other transmission method may be the lever to unlock really complex systems.
I think it's time people read up a bit on some computational history. Quite a bit of this stuff was worked on in the old days before the x86 started to dominate the world with a saurian single-core brutishness. Learn about Occam for example.
And Peter, before I "explain in full detail and completely how it would actually work" how about you explain in full detail and completely how you're going to fund my research? ;-)
tim PS another 'randomly chosen' sigline that manages to be eerily appropriate -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Try not to let implementation details sneak into design documents.