HydraTools and minimal images

Klaus D. Witzel klaus.witzel at cobss.com
Sat Feb 16 14:48:55 UTC 2008


On Sat, 16 Feb 2008 13:56:54 +0100, Igor Stasenko wrote:

> On 16/02/2008, Klaus D. Witzel 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.

Ahh, now we are talking events :)

> This can be done using current set of features (channels), no need to
> put this code into VM.

Exactly, I thought about the same.

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

For dead/alive: an interval timed object which periodically (3-4 secs)  
sends "I'm alive" ;-)

> Channels are implemented using events, e.g. when you putting something
> in channel, in reality its an event posted to corresponding event
> queue.

Sure.

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

Still unclear: your user (a developer) has an index, say an element from  
(1 to: n), for which you want to return her/him a HydraInterpreter  
instance from now on?

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

Cannot understand "as an interpreter at VM side": didn't you write that  
everything is an object on the Smalltalk side (even your handles, which  
seem to represent the magic)? To be sure, I didn't think about anything  
"behind" your handle.

And by HydraInterpreter instance I meant the one from your discussion with  
Keith. Perhaps I associate your handle with an instance of  
HydraInterpreter, whereas you treat them as different objects. No problem,  
just put a "represents" symbol between them.

BTW: isn't the HydraInterpreter name misleading (and causing confusion in  
the above). How about using another name, without "interpreter" in it,  
because your "as an interpreter at VM side" is something else.

> Objects can contain a random values, nothing bad will happen if you
> pass it to primitive.

Thanks to the implementor of the primitive and to the writer of the  
corresponding test cases ;-)

>
> A primitive #interpreterInstanceAt: will be refactored to return a
> freshly created HydraInterpreter instance.

Ah, this is where you map elements of (1 to: n)? But didn't you write you  
are concerned that is slow, because you always have to enumerate your 100  
instances (example)?

And, did you consider to implement #= and #hash which are now necessary  
for all your freshly created HydraInterpreter instances?

> The rest of code have to
> deal with interpreters using HydraInterpreter, not handles or indexes.

Except when asking for (aHydraInterpreter index), because otherwise nobody  
except you would know?

> So, in #doit: at: , first you converting an index to HydraInterpreter
> instance (by invoking primitive),

No, I don't invoke primitives; I send messages to your Hydra  
classes+instances, whatever they are or will be :)

> and then you're free to do anything you want with it.

No doubt.

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





More information about the Squeak-dev mailing list