<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jason Johnson wrote:
<blockquote
cite="mid:aa22f0200710241347y5f808437j2211997e49dda425@mail.gmail.com"
type="cite">
<pre wrap="">On 10/24/07, Jason Johnson <a class="moz-txt-link-rfc2396E" href="mailto:jason.johnson.081@gmail.com"><jason.johnson.081@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">No, the plan was that since in Smalltalk objects are mutable, I will
have to pay an extra cost for internal message sends and have the VM
do a deep copy for the sent objects.
</pre>
</blockquote>
<pre wrap=""><!---->
Ack, terminology overload. :) What I meant here is, obviously if I
sent a message between two literal images there is no choice but to do
a deep copy. Erlang gains some benefit from sending interprocess
messages where the sender and receiver are in the same literal image
via reference, but I can't because Smalltalk can mutate variables. So
this means I have to do the deep copy in *every* case. Unless I make
some changes.
</pre>
</blockquote>
Hi,<br>
<br>
No, you'd not have to deep copy every time you send the messages. You
can send references and when accessing them in the remote image (or
image B if you prefer) you can ask the local image (or image A if you
prefer) to send the missing data. Now this assumes that the objects in
image A didn't change in the meantime. Yikes. Problems are getting
worse. You can't avoid them. There is no silver bullet with this
attempt at simplifying concurrency. It's a harsh reality.<br>
<br>
Cheers,<br>
<br>
Peter<br>
<br>
</body>
</html>