HydraTools and minimal images

Klaus D. Witzel klaus.witzel at cobss.com
Wed Feb 13 13:25:52 UTC 2008


Hi Igor,

on Wed, 13 Feb 2008 13:24:05 +0100, you wrote:

> On 13/02/2008, Klaus D. Witzel wrote:
>> Hi Igor,
>>
>> on Wed, 13 Feb 2008 09:35:09 +0100, you wrote:
>>
...
>> > But before going deep, i would like to get some feedback on channels
>> > implementation.
>>
>> If I had a wish free then I'd say that Hydra's channels could provide  
>> the
>> [a sensible part of] existing vocabulary of Socket (Socket's messages
>> categories #open, #queries, #receiving, #sending and #waiting).
>>
>
> There is, a waiting (hidden from your eyes).
> You can check the HydraReceivingChannel>>startListening: aBlock
>
> VM signals a semaphore, when data arrives on channel, so a process
> which is waiting on that semaphore is then awaken and can do anything
> he needs to handle incoming packet.

If these you lines are related to my #waitForDataFor:ifClosed:ifTimedOut:  
question (I assume that):

a] the timeout can occur while waiting (listening)
b] the close can occur while waiting (listening)
c] data can arrive while waiting

Case c] is easy with the #startListening: but how about capturing the  
other two cases?

> Actually, you can omit using semaphore, and just pull data from
> channel at any time you need.

It would have to know that there's no data to pull (and why that is so),  
that is what #waitForDataFor:ifClosed:ifTimedOut: is about (besides  
pulling data).

> The readData primitive works pretty straightforward: If there is data
> waiting on channel, you'll receive a bytearray, if not - you just
> receive a nil in response, indicating that channel input queue is
> empty.
> So, you can implement own listening scheme, which polls channel for
> data periodically, and if there is no data received after supplied
> timeout, evaluate a onTimeOut handler..

IC.

>> This would make porting Socket-based applications easier and can  
>> leverage
>> existing knowledge about Sockets.
>>
>> > There is some very interesting alternatives, which should be  
>> considered.
>> ...
>> > ---
>> > Alternatives:
>> ...
>> > - adding some feedback mechanism, when incoming packet can't be
>> > delivered (when channel input queue is full, or simply there is no
>> > channel with given credentials).
>>
>> Considering a port one of my projects which currently is using Sockets,
>> what I'm missing is something like #waitForDataFor:ifClosed:ifTimedOut:
>>
>
> A channels is unidirectional. You sending data and have no feedback.
> It works in same way as UDP sockets.
> But on top of UDP you can always build more sophisticated layers (as
> bidirectional streams), where you can introduce behavior like
> #waitForDataFor:ifClosed:ifTimedOut:.
>
>> Is something like that possible with the Hydra channels primitives?
>
> ... and there is no need to make it at VM level. It can be easily done
> at language level.
>
>>
>> > I'm not sure, if this is really needed to be implemented by VM. An
>> > efficient error/feedback mechanisms can be implemented very easily at
>> > language side.
>>
>> It wouldn't need more/other error/feedback than what Socket provides
>> today, IMHO.
>>
>> BTW: what's happening now if the second .image does no longer respond to
>> the first .image, how can/does the other .image get known to this?
>
> Again, there is no 'response' in any means.

So I have to teach the app's users, "there's no response" ;-)

> Channels just listening
> for data. You can send data to channel, but you don't getting any
> feedback about if it was delivered or handled.

More seriously, I understand that in order to save the whole app from  
potentially "freezing on no response", some timeout mechanism needs to be  
added. But timeout alone cannot find out that the other .image has gone  
away. Is there something you would suggest for checking the other .image  
is still alive (or not alive)?

NB: this check is independent of using Sockets or Hydra channels between  
any pair of Hydra .images, but it looks like there can be easier control  
with Hydra because everything is on the same machine.

> To build a system with feedback all you need is to setup two channels
> (one for each image) and create a feedback protocol, like, when
> channel receives a message, it sends a message back, that he is
> actually received it :)

Sure, DIY :)

> As a small exercise of bidirectional communication, you can check
> HydraPing class.

Sure.

>> /Klaus
>>
>>
>





More information about the Squeak-dev mailing list