On 10/22/07, Sebastian Sastre ssastre@seaswork.com wrote:
1.4 I'm interpreting the normal thousands of processes Erlang
manages as analogue (so similar in function) to one of this tides and point why we cannot make tides of Smalltalk message sends in an image?
We can. In fact, I think we could do it right now with the existing VM and some packages that have been written already.
3. If I understood well, Erlang's main strenght is not that it has
functions to do things but that it has a message passing technique really great that was designed to take advantage of parallelism in a simple way efficiently and making processes very cheap (ceaper than the OS ones).
Erlang processes are much cheaper then OS processes *and* OS threads. But then, so are Smalltalk's. The only difference is that Erlang processes are encapsulated entities that have no shared memory [1], while Smalltalk's do.
The intersticial space of virtual objects, AKA messages sends, can
be "Erlanged" by making each message send to be in a "process" (the cheap ones) of it's own like Erlang messages between "process"?
Well, keep in mind, Erlang is a functional language and code written in uses functions. Message sends are for communicating between processes.
Same in other words: What consequences will affect us if we make a Squeak to use a VM
that to pass messages use processes ala Erlang (that are simple, cheap, efficient and scalable in a world of "cores")?
If you mean every Smalltalk message send is what an Erlang message send is, then the results would be devastating. As I mentioned above, Erlang does it's work with functions. In Smalltalk, the equivalent method of doing work is what Smalltalk calls "messages". In Erlang there is a concept of sending messages between processes, and I would do the same for Smalltalk.
Can this allow us to assimilate in the Smalltalk's objects paradigm
the Erlagn's process paradigm? This is: will this allow us to gain that parallelizing benefits preventing us to change the programing paradigm?
We can, and it would [2]. But I think we should, at least at first, make inter-process message sends very obviously different from inter-object message sends. It would be possible, for example, that objects of type "Process" have a different way of handling messages so that:
(Processes at: 'bank account') addUSD: 5000
Is actually an inter-process send, but I would still want to use the ! syntax, or something equivalent so it's completely obvious that we are doing something different.
Inter-process message sends have their own lookup complexity that I think should be separate from the inter-object message sends we have now. For example, in Erlang if you send a message to a process that happens to be in the same image, a simple reference copy happens (no danger since variables are immutable). The other two cases would be: a different OS/native thread in the same image, and a totally different image (same computer or on the network).
Now if what you're talking about is basically promoting every object to it's own process (using the terms I have described so far), then I haven't really given this much though. This would be a totally different paradigm and area of research (maybe like CORBA?). Though I'm sure someone somewhere has done research on it (or is currently). :)
Sebastian Sastre PD: I've tried to imagine if this saves us from having to make code trhead safe or not. I was unable to refutate this by myself so I also ask kindly that the most experienced and critic minds collaborate on this regard.
Us as people who use Smalltalk? Yes I believe it does. It doesn't make it impossible to make a design that has deadlocks, but imo the big win is that these concerns move to design time instead of implementation time.
[1] This is enforced by the language. As far as I know, the processes actually share the same heap, etc.. They just don't know it and can't take advantage of it :)
[2] Well, I believe so anyway, and aim to find out. The issue is that Erlang has it easy: you *can't* share data at a language level in Erlang. In Smalltalk this gets a little tricky, mainly due to one of Smalltalk's greatest strengths: Classes are live objects (with state and so on). I believe this can be overcome, while preserving the Smalltalk semantics, but I can't prove it yet. :)