On 15/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Fri, 15 Feb 2008 09:47:54 +0100, Igor Stasenko wrote:
>
>
>  > On 15/02/2008, Klaus D. Witzel wrote:
>  >> On Thu, 14 Feb 2008 22:52:41 +0100, Igor Stasenko wrote:
>
> ...
>
> >>  > Of course, a bidirectional protocol will look as much as close to
>  >>  > sockets :)
>  >>
>  >> NB, some fruits with HydraSMS and its same-method principle, a #doit
>  >> from
>  >>  a workspace, just out of the blue and neither any other preparation nor
>  >>  other knowledge:
>  >>
>  >>   | sms | sms := HydraSMS doitAt: 2.
>  >>   sms atHomeDo: [Transcript cr; show: 'Hydra .image #2 is up and
>  >> running']
>  >>
>  >>  , for which #doitAt: automagically compiles the very-same method in the
>  >>  other image :)
>  >>
>  > Be warned, that using index instead of handle to identify interpreter
>  > is not a good way.
>
>
> Well, that's exactly what the higher levels are good for: tell the user
>  what's up, without demanding from him to know anything about the
>  internals. Of course I cannot post the above example so that it rises all
>  possible exceptions, so at the moment you have to engage imagination and
>  *think* that proper notification is given (NetworkContext does check and
>  report whatever problem it finds).
>
>
>  > All primitives are handle-oriented, an #at: methods simply doing:
>  > HydraVM interpreters at: n.
>
>
> We cannot really want the user to type in values for your
>  interpreterHandle, unless they are used to typing MS$ registry keys and
>  *demand* that from us ;-)
>
Of course not, that's why i added #at: in different places. I'm too
lazy myself for typing:

HydaVM doit: '...' on: (HydraVM mainInterpreter)

when i simply can:

HydaVM doit: '...' at: 1

>
>  > There is a danger, that when in future i add code to shutdown images,
>  > then indexed can be changed, and thus, code based on indexes might
>  > fail, because if you having 3 interpreters running:
>  >
>  > #(x y z)
>  >
>  > and you shutting down 2nd one,
>  > then 'HydraVM interpreters' will return array with 2 handles:
>  > #(x z) , so #at: 3 will lead to error,
>
>
> What error, Smalltalk's Error instance? Image crash? Interpreter crash?
>  Executable crash? OS crash? Market melt-down? Blackout of the Internet?
>
a simple index out of bounds error.

>  And, BTW, why would you make that undeterministic? I'm used to multi-CPU
>  machines for decades and we always index the physical processor (also
>  virtual processor) by its constant index. I could send you an indexing
>  schema in case you need one.
>

Remember, that interpreters now is the objects, regardless that most
of it's functionality are sitting in VM. But there actually was idea
to make them behave much like real ST objects:
 you can create new instance of HydraInterpreter, load image in it ,
run commands e.t.c.
and then , when you no longer need it, it will simply be freed once GC
will do it's work :)
There can be a another, useful macro operations on interpreters, for
instance creating a copy.

So, you can do:
 myCopy := interpreter copy.

to create new instance of interpreter with exactly same state & object
memory as original.
In that way, it can be useful for forking complex computations without
need in initializing all forked images personally. I can take single
interpreter, load all i needed to it's object memory, simply preparing
it for something dramatical :)
and then fork as many new interpreters as i need to begin rock&roll.
Of course, you may do something similar by snapshotting image, and
then starting it couple of times. But it's much less effective and
forcing to pass startup phase when loading, which you may not want.

There could be another useful things, like suspending, profiling,
inspecting state e.t.c.

I can actually kill the native thread, but keep interpreter's state
and object memory. And then start debugging, using special
interpretStep() function which will evaluate a single bytecode per
call.

For this reasons, i'd like to operate with interpreters using handles
instead of indexes.
This, in particular, can guarantee that if you save your image which
contains references to handles, they will render invalid during next
squeak session. While indexes is not.

>  > and #at: 2 will return different handle.
>
>
> I don't see much danger with different handles, since I will be carefully
>  reading your future Hydra release notes :)
>
>  >>  /Klaus
>  >>


-- 
Best regards,
Igor Stasenko AKA sig.