On 16/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
>
> There's always some price to pay, when you want to maintain control over
> your asynchronous computations. Another possibility would be to base
> absence(dead), presence(alive), other state(busy,idle) of your interpreter
> instances on events. Have you considered using events for that, would that
> be easy to implement in Hydra?
>

Well, i can add some code at the end of image startup phase
broadcasting to others that new image is ready for work. As well as,
at shutdown, a broadcast that it's going to vanish.
This can be done using current set of features (channels), no need to
put this code into VM.
In same way, for a busy/idle state: you may put code in image to
declare by yourself, when it is busy or idle, and respond with
appropriate message on request, if needed.
Channels are implemented using events, e.g. when you putting something
in channel, in reality its an event posted to corresponding event
queue.

>
> > Okay, i think i have a solution which will suit both of us.
>
> For the records: in the previous I just tried to use *your* existing index
> into *your* existing collection :)
>
> > By adding a HydraInterpreter class, instances of which will be used in
> > primitives.
>
> That sounds good.
>
> > Class should have two fields: index and handle.
> > Primitives then checking:
> > - if given argument is of class HydraInterpreter,
> > then reads index and handle.
>
> How would you map one of these indexes to its corresponding instance of
> HydraInterpreter, how would your #doit:at: do that mapping?
>

index and handle is the result of previous calls to primitives which
should return a HydraInterpreter instance from now.

> > then checks if by given index VM having same interpreter handle, as
> > specified in HydraInterpreter instance.
> > If not, then it tries to search its list of interpreters to find given
> > handle, and if found, updates index automatically.
> > If handle not found, then primitive fails.
> >
>
> Looks like a lot of work (if only for your index); did you compare against
> simple (HydraInterpreter allInstances) ? This (or something like this)
> needs only be done after a new HydraInterpreter was
> created(copied)/started, and, depending on needs, after one of the
> HydraInterpreter instances gone away.
>
..erm.. do you mean by HydraInterpreter  as an interpreter at VM side,
or as an object?
Objects can contain a random values, nothing bad will happen if you
pass it to primitive.

A primitive #interpreterInstanceAt: will be refactored to return a
freshly created HydraInterpreter instance. The rest of code have to
deal with interpreters using HydraInterpreter, not handles or indexes.
So, in #doit: at: , first you converting an index to HydraInterpreter
instance (by invoking primitive), and then you're free to do anything
you want with it.

> And Smalltalk's collection hierarchy has subclasses which are accessible
> by keys (indexes) which don't need to be stored anywhere (the diagram on
> page 146 of the Blue Book).
>
> /Klaus
>


-- 
Best regards,
Igor Stasenko AKA sig.