Hello,

On Mon, Jul 7, 2008 at 2:38 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 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.
>



The detailed documentation for current FarRef and Island's implementation
could be found in the Croquet image (look in Island class comments).
Thanks Andreas Raab for that.

Regards,
Nikolay




>
> >>
> >
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080707/07c1b0bf/attachment.htm