<!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:aa22f0200710250845i400d9523va131ca4b7239009b@mail.gmail.com"
type="cite">
<pre wrap="">On 10/24/07, Sebastian Sastre <a class="moz-txt-link-rfc2396E" href="mailto:ssastre@seaswork.com"><ssastre@seaswork.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">So I'm stating here that in a smalltalk image of the future *every object
should have a process*. Every instance. All of them.
</pre>
</blockquote>
<pre wrap=""><!---->
That is an interesting idea. That would open a door to a new way of
Garbage collection, because it can then be tied to the exit of a
process.
</pre>
<blockquote type="cite">
<pre wrap="">Said that I return to the problem you stated about the need of copy copy
copy, saying that this premise changes things and you don't need to copy
anymore because a VM like that, no matter who or when, an instVar of an
object is to be modified it will provide you of guarantee that the write
will be made by the process that corresponds to that instance.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, in such a system, you don't need to copy because all that gets
passed around are references to processes.
</pre>
</blockquote>
hi,<br>
<br>
What? That just won't work. Think of the memory overhead. <br>
<br>
Tying an object instance to a particular process makes no sense. If you
did that you'd likely end up with just as many dead locks and other
concurrency problems since you'd now have message sends to the object
being queued up on the processes input queue. Since processes could
only process on message at a time deadlocks can occur - plus all kinds
of nasty problems resulting from the order of messages in the queue.
(There is a similar nasty problem with the GUI event processing in
VisualAge Smalltalk that leads to very difficult to diagnose and
comprehend concurrency problems). It's a rats maze that's best to avoid.<br>
<br>
Besides, in some cases an object with multiple threads could respond to
many messages - literally - at the same time given multiple cores. Why
slow down the system by putting all the messages into a single queue
when you don't have to!?<br>
<br>
Tying an object's life time to the lifetime of a process doesn't make
sense since there could be references to the object all over the place.
If the process quits the object should still be alive IF there are
still references to it.<br>
<br>
You'd need to pass around more than references to processes. For if a
process has more than one object you'd not get the resolution you'd
need. No, passing object references around is way better.<br>
<br>
Even if you considered an object as having it's own "logical" process
you'd get into the queuing problems hinted at above.<br>
<br>
Besides objects in Smalltalk are really fine grained. The notion that
each object would have it's own thread would require so much thread
switching that no current processor could handle that. It would also be
a huge waste of resources.<br>
<br>
Again, one solution does not fit all problems - if it did programming
would be easier.<br>
<br>
All the best,<br>
<br>
Peter<br>
<br>
</body>
</html>