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