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
|