Hello,
<br><br><div class="gmail_quote">On Mon, Jul 7, 2008 at 2:38 PM, Igor Stasenko &lt;<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2008/7/7 Klaus D. Witzel &lt;<a href="mailto:klaus.witzel@cobss.com">klaus.witzel@cobss.com</a>&gt;:<br>
<div><div></div><div class="Wj3C7c">&gt; [sorry for cutting multiple Re&#39;s from the subject line]<br>
&gt;<br>
&gt; On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:<br>
&gt;<br>
&gt;&gt; 2008/7/7 Klaus D. Witzel:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Mon, 07 Jul 2008 10:49:06 +0200, Igor Stasenko wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; 2008/7/7 Andreas Raab :<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Peter William Lount wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Why prevent others from having their needed multiple native threads?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; It&#39;s not about preventing anything. If you have a proposal for how to<br>
&gt;&gt;&gt;&gt;&gt; do<br>
&gt;&gt;&gt;&gt;&gt; multiple threads per image I will most definitely listen, and if it is<br>
&gt;&gt;&gt;&gt;&gt; a<br>
&gt;&gt;&gt;&gt;&gt; reasonable proposal (i.e., one that can be implemented with bounded<br>
&gt;&gt;&gt;&gt;&gt; resources) I will even try to find funding for it. However, until such<br>
&gt;&gt;&gt;&gt;&gt; a<br>
&gt;&gt;&gt;&gt;&gt; time that there is a proposal I will drop this pointless discussion<br>
&gt;&gt;&gt;&gt;&gt; since,<br>
&gt;&gt;&gt;&gt;&gt; simply put, there is nothing to discuss here. The only available path<br>
&gt;&gt;&gt;&gt;&gt; at<br>
&gt;&gt;&gt;&gt;&gt; this point is by using one native thread per image and consequently<br>
&gt;&gt;&gt;&gt;&gt; that&#39;s<br>
&gt;&gt;&gt;&gt;&gt; what&#39;s going to happen.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I have some ideas of using Island/Vat model in future CorruptVM project.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I&#39;m not going into deep detail right now, but the essence of model is<br>
&gt;&gt;&gt;&gt; following:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - an Island is the group of objects sharing same memory region.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; s/memory region/owner/ where owner can be sort of &quot;deputy&quot; of memory/VM<br>
&gt;&gt;&gt; monitor. A very interesting concept indeed, thanks for posting :)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I think that can be addressed with a small trick in Squeak&#39;s VM and *no*<br>
&gt;&gt;&gt; extra object header (using one of the Metaclass ideas that Alex+my<br>
&gt;&gt;&gt; discussed in Bern for Goya =&gt; coloring of metaclass instances).<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Yes, there is no need in having extra state which indicates to which<br>
&gt;&gt; island belongs object.<br>
&gt;&gt; It is impossible by design to get direct reference to any object which<br>
&gt;&gt; not belongs to same island.<br>
&gt;<br>
&gt; I think that, &quot;ref to any object&quot; can be restricted to &quot;any receiver&quot;, just<br>
&gt; so when sending something. When not sending something (=&gt; when just peeking<br>
&gt; and poking oops) then belonging to some island is of not so much importance<br>
&gt; (this &quot;receiver detail&quot; is why I suggested s/memory region/owner/).<br>
&gt;<br>
&gt; You agree? Of course the &quot;any receiver&quot; detail is relative to SqueakVM;<br>
&gt; CorruptVM&#39;s mileage may vary.<br>
&gt;<br>
</div></div>of course, a difference lies only in a way how we sending message to<br>
object, wrapped by FarRef.<br>
<div class="Ih2E3d"><br>
&gt;&gt; For referencing objects from different island there will be a FarRef,<br>
&gt;&gt; which will be responsible for handling message sends to object in<br>
&gt;&gt; different island.<br>
&gt;<br>
&gt; Hah :) a natural extension of the #doesNotUnderstand: concept (with<br>
&gt; FarMessageSend a subclass of MessageSend :)<br>
&gt;<br>
</div>Nah!<br>
You don&#39;t need to use DNU pattern, since you free to change a message<br>
sending semantics for FarRef.<br>
In this way, FarRef will act as transparent proxy, and ALL messages to<br>
it will lead to sending message to wrapped object which is located in<br>
different island.<br>
A FarRef could reserve a special selector for itself, like<br>
#performLocal: selector withArguments: args<br>
to send message to a FarRef object, not to wrapped object.<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br><br><br>The detailed documentation for current FarRef and Island&#39;s implementation could
be found in the Croquet image (look in Island class comments). <br>

Thanks Andreas Raab for that.<br>

<br>

Regards,<br>

Nikolay<br><br><br>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c"><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</div></div></blockquote></div><br>