On Sun, Oct 14, 2012 at 2:39 PM, Frank Shearar <frank.shearar at gmail.com>wrote:
>
> In Erlang you can get away with this because of its ubiquitous
> immutability. But removing all concurrency from an image means that
> you can _today_ (without waiting for the VM support, in other words)
> start doing share-nothing message passing concurrency.
>
> It might be cheaper computing-wise to use green threads, but for us it
> might be (MUCH) easier to pay the computing cost of multiple images
> than trying to make things in the image immutable.
>
> For instance, Point is perfectly safe to share - mutating methods
> return new Points - but you can't share an Array without the mere
> convention of copy-before-changing. Even if one uses persistent data
> structures (something both Levente and I have done), you still have to
> rely on people not violating the contract of the structures (by
> exploiting a bug in the data structures, by breaking encapsulation
> through #instVarAt:put:, ...). And the cost of this violation is dear:
> random stuff breaks for no apparent reason.
>
> frank
>

Won't running dozens/hundreds of independent images that only communicate
by messages return us to manual memory management? You could always return
a newly computed copy of the data requested on each message but that could
be a major performance hit as well.

rado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20121014/29e08bb2/attachment.htm