On 22/03/2009, at 9:48 PM, Igor Stasenko wrote:

> Sorry, my fault. You need to sync in both cases (even with green
> threads).

Green threads make some underlying implementation details easier, but
at the language level the difference they make is determined by the
interleaving guarantees they provide, and the extent to which the user
can take advantage of those guarantees e.g. the yield-point model.

IMO the solution to concurrency is not to simply add native threads -
it also requires a more functional type of programming, and that can
be largely provided by immutable data structures and more powerful
abstractions, such as those provided in Clojure.

I'm not suggesting adding native threads to Squeak. Squeak is quite a
minefield as it is. I think it's time for a new model of Smalltalk
that includes native threads from the get-go, and is a rethinking of
the Smalltalk tradition, in the same way that Clojure is a rethinking
of the Lisp tradition. The parallels between Lisp and Smalltalk, in
terms of their paradigmatic roles, market issues, and communities, is
quite striking. Why should these two powerhouses of beautiful
programming not *both* be reborn.

> There is another problem, that squeak processes is cheap (few bytes in
> object memory), while allocating new native thread consumes
> considerable amount of memory & address space. So, if you map
> Processes to native threads, you will lose the ability in having
> millions of them, instead you will be limited to thousands.

You don't need a 1:1 mapping. You can use a native thread pool to
execute lightweight threads. Erlang manages with huge numbers of
language level processes.