2008/7/7 Klaus D. Witzel <klaus.witzel at cobss.com>:
> [sorry for cutting multiple Re's from the subject line]
>
> On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:
>
>> 2008/7/7 Klaus D. Witzel:
>>>
>>> On Mon, 07 Jul 2008 10:49:06 +0200, Igor Stasenko wrote:
>>>
>>>> 2008/7/7 Andreas Raab :
>>>>>
>>>>> Peter William Lount wrote:
>>>>>>
>>>>>> Why prevent others from having their needed multiple native threads?
>>>>>>
>>>>>
>>>>> It's not about preventing anything. If you have a proposal for how to
>>>>> do
>>>>> multiple threads per image I will most definitely listen, and if it is
>>>>> a
>>>>> reasonable proposal (i.e., one that can be implemented with bounded
>>>>> resources) I will even try to find funding for it. However, until such
>>>>> a
>>>>> time that there is a proposal I will drop this pointless discussion
>>>>> since,
>>>>> simply put, there is nothing to discuss here. The only available path
>>>>> at
>>>>> this point is by using one native thread per image and consequently
>>>>> that's
>>>>> what's going to happen.
>>>>>
>>>>
>>>> I have some ideas of using Island/Vat model in future CorruptVM project.
>>>>
>>>> I'm not going into deep detail right now, but the essence of model is
>>>> following:
>>>>
>>>> - an Island is the group of objects sharing same memory region.
>>>
>>> s/memory region/owner/ where owner can be sort of "deputy" of memory/VM
>>> monitor. A very interesting concept indeed, thanks for posting :)
>>>
>>> I think that can be addressed with a small trick in Squeak's VM and *no*
>>> extra object header (using one of the Metaclass ideas that Alex+my
>>> discussed in Bern for Goya => coloring of metaclass instances).
>>>
>>
>> Yes, there is no need in having extra state which indicates to which
>> island belongs object.
>> It is impossible by design to get direct reference to any object which
>> not belongs to same island.
>
> I think that, "ref to any object" can be restricted to "any receiver", just
> so when sending something. When not sending something (=> when just peeking
> and poking oops) then belonging to some island is of not so much importance
> (this "receiver detail" is why I suggested s/memory region/owner/).
>
> You agree? Of course the "any receiver" detail is relative to SqueakVM;
> CorruptVM's mileage may vary.
>
of course, a difference lies only in a way how we sending message to
object, wrapped by FarRef.

>> For referencing objects from different island there will be a FarRef,
>> which will be responsible for handling message sends to object in
>> different island.
>
> Hah :) a natural extension of the #doesNotUnderstand: concept (with
> FarMessageSend a subclass of MessageSend :)
>
Nah!
You don't need to use DNU pattern, since you free to change a message
sending semantics for FarRef.
In this way, FarRef will act as transparent proxy, and ALL messages to
it will lead to sending message to wrapped object which is located in
different island.
A FarRef could reserve a special selector for itself, like
#performLocal: selector withArguments: args
to send message to a FarRef object, not to wrapped object.

>>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.