Re: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger

Sorry for the multiple replies, but for some reason the HTML
formatting of quoting indentation of my reply doesn't appear to be
showing up right in the posting as far as I can see on the web, so I'm
trying to get it right (if anyone knows why google groups does this,
or how to get google groups to send your own posts back to you so you
can see how they look, please let me know, since Google apparently
provides absolutely zero tech support for posting problems).

On Jun 2, 6:12 am, J J <[email protected]> wrote:
> Thanks very much for answering this.  At the moment, this group is forwarded to an email I don't read much.
>
> The actor model can, as you say, be added at any time as a library.  One property that Erlang has that
> would require a VM change is that Erlang itself can and will run in multiple "OS threads".  Each of these
> threads runs a scheduler and when ever the user creates a new "process" it will go to one of these
> schedulers automatically.  This lets the programmer gain the speed up of multiple CPUs without the huge
> amount of pain involved in a fine-grain locked scheme.
>
> I'm also not sure what it would be like adding exactly Erlang's scheme to Smalltalk, but I think it would
> be a positive.  The biggest difference would be that currently Smalltalk "processes" can share state with
> other processes, while in Erlang a "process" is more like a Unix process, i.e. no possible way for another
> process to see the structures inside it.
>
> There are also other options for concurency, e.g. the "futures" model used by the E language and by a
> system built in Squeak Smalltalk called Croquet.

There seems to be some confusion in the discussions caused by my
comment about the difficulty of making the VM multi-threaded.
Choosing a different model for Smalltalk concurrency has almost
nothing to do with the point I was making.  Erlang's model may or may
not be a good one (personally I think it is a nice in a small way
following the functional philosophy, but I'm not at all convinced that
passing only lightweight values with no other shared state is good
enough for what people do in the real world).

But regardless of the concurrency model of the target language, if you
want multiple things happening at the same time then the VM needs to
be internally multi-threaded with shared state, regardless of how the
threads communicate in the target language.   The Strongtalk VM stores
all the bytecodes, classes, etc on the same shared heap.   Garbage
collection, reflective modification, etc.  all modify that heap, and
those modifications must be syncronized across all running threads,
processes, or whatever.

Of course, you could implement the Erlang model by making a completely
separate copy of the entire VM/heap for each thread, but you can do
that in any language without modifying the VM at all.  That's called
an 'OS process'.  Or you could 'compile' a bunch of lighter-weight
kind of Erlang-style threads into a single thread/process, but such
threads won't run concurrently on a multi-core system.  None of these
things have much to do with making the VM multithreaded.

-Dave


> Date: Wed, 14 May 2008 21:41:16 -0700
> From: [email protected]
> To: [email protected]
> Subject: Re: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger
>
> [...]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---