On 10/21/07, Peter William Lount peter@smalltalk.org wrote:
tim Rowledge wrote:
Ok, so if you really are talking about a "strict" Erlang style model with ONE Smalltalk process per "image" space (whether or not they are in one protected memory space or many protected memory spaces) where objects are not shared with any other threads except by copying them over the "serialization wire" or by "reference" then I get what you are talking about.
That is a strange way of putting it. The fact is, Erlang has many processes per image. Many more then you could ever get as real processes or native threads (as a test I made a little program that spawned 64 *thousand* threads and passed messages between them on my laptop).
But with their model, process creation is extremely cheap. And since there is no sharing as far as the language is concerned, there is no need for locking to slow everything down.
Smalltalk can do this too. I think it needs a little work still, but I'm optimistic about what can be done here.
However, you'll still end up with concurrency control issues and you've got an object version explosion problem occurring as well. How will you control concurrency problems with your simplified system? Is there a succinct description of the way that Erlang does it? Would that apply to Smalltalk?
Much like how Smalltalk does it, as it turns out. That is, you don't have a version problem so much as you have "old" and "new". So when ready you send the "upgrade" message to the system and all new calls to the main functions of a process will be the new version. All currently running code will access the old code until it's completion, and all new code runs in the new space.
You simplified concurrency system also dramatically alters the Smalltalk paradigm.
The current paradigm is fine-grained locked/shared state. In my opinion and the opinion of many (probably most in fact, outside of the Java community) people who are more expert is this area then you or I, we *have* to move away from this paradigm.
Is this the approach that Cincom is using in their Visual Works system? They seem to not be embracing the notion of native threads.
Thank God. :)
However it's also unlikely that they are embracing the notion of only ONE Smalltalk process per image either.
If I understand you correctly, then I would suggest not to use the word "image" as this is confusing. Another way to put it would be "each process has it's own view of the world". And honestly, what is the problem you see with this?
Right now, if you run two separate images with only one thread or process, then you have two processes that each have their own set of objects in their own space interacting with each other.
Now we add a way for one image to send a message *between* images. Perhaps the VM can detect when we are trying to do this, but instead of complicating the default Smalltalk message sending subsystem, lets make it explicit with some special binary message:
Processes at: 'value computer' ! computeValue.
Now we have the ability to send messages locally within a process, and a way of freely sending between processes. No locking and the problems associated with locking.
So, now what is stopping us from moving this separate process *inside the same image*? If you fork a process and he starts making objects, no other processes have references to those objects. No shared state issue there. This part could work right now today with no changes to the VM.
The only issue I can think of are globals, the most obvious being class side variables. Note that even classes themselves are not an issue because without class side variables, they are effect free (well, obviously basicNew would have to be looked at).
But I think this issue is solvable. The VM could take a "copy on write" approach on classes/globals. That is, a class should be side effect free (to itself, i.e. it's the same after every call), so let all processes share the memory space where meta-class objects live. But as soon as any process tries to modify the class in some way (literally, it would be the class modifying itself), he gets his own copy. Processes must not see changes made by other processes, so a modification to a global class is a "local only" change.
Of course the only big thing left would be; what happens when we add a new class. But Erlang has had success with the old/new space approach, and what Smalltalk has now is very similar.