HydraTools and minimal images

Igor Stasenko siguctua at gmail.com
Thu Feb 14 10:30:12 UTC 2008


On 14/02/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> On Thu, 14 Feb 2008 02:20:02 +0100, Igor Stasenko wrote:
>
>  > Updated a HydraVM dev notes.
>  > Some words about legacy plugins and added HydraStream into wish list :)
>
>  > http://squeakvm.org/~sig/hydravm/devnotes.html
>
>
> You might want to add HydraSMS to the wish list (Hydra Synchronous Message
>  Send, just claiming the name for now :)
>
>  I will attempt a port of my NetworkContext project to HydraSMS, of course
>  after your project supervisor has approved the test cases we discussed
>  earlier :)
>
>  The main purpose of HydraSMS is to provide a simple, lightweight, easy
>  usable [etc, etc] synchronous mechanism for exchanging messages between
>  two endpoints of a network (between two Hydra .images). This can be used
>  for controlling any form of asynchronous computation in multiple Hydra
>  .images, for example without always having to compile #doit's (imagine
>  10'000 requests per minute polluting the .changes file ;-)
>

Hehe, i assuming you realize that #doit's channel is just a system
default channel, which should be available for anyone. You can always
create own, pervasive channels, handling a data in pervasive manner
without polluting any files :)

It's as easy as doing:

myOtherImage := HydraVM loadAndStartNewImage: 'myOther.image'.

HydraVM doIt: 'HydraChannel listen: #myPervasiveChannel onReceive: [:data |
	<place your code here>	 ]' on: myOtherImage

now your just loaded image listening a #myPervasiveChannel
and you free to send anything to it :)

>  The unit of transfer is Smalltalk's block (i.e. what is transferred is
>  control, back and forth). All that is needed is to compile the very same
>  method in both Hydra .images once before using it. From a security point
>  of view, you are supposed to trust the very same method in both .images ;-)
>
>  Example with bells and whistles, except exception handling:
>
>  mySMSexample
>   | sms tmp |
>   sms := HydraSMS with: #myChannel at: 2.
>   "I'm now running in the other image, in which I do, "
>   sms atHomeDo:
>   ["this block is performed back in the initiating .image"
>     sms nextStringPut: 'a parameter'; atWorkDo:
>    ["and this nested block is performed in the other .image"
>     tmp := sms nextString "get the parameter"
>    ]
>   ]
>   "both sides always return self"
>
>  HydraSMS (aka NetworkContext) provides protocol for #nextString* and I
>  think about supporting SmartRefStream as well.
>

ermmrmrm.. can't quite understand what given example suppose to do.

suppose you having a method in HydraSMS class
foo: aString

and now, if you wish that by invoking a #foo: in your 'home' image,
string should be passed to 'work' image, you write there:
mychannel send: aString.

At other side, when you received a string, it may be collected
somewhere, so on next call to #nextString, it will return the first
available string in FIFO manner.

I don't see a reason in transferring a blocks (compiled bytecode),
since you stating, that both images containing very same code (and if
not, you can always perform a pervasive doit to make it appear :).

>
>  /Klaus
>

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list