Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 392

News	FAQ
Search	Home

A Link is not just a Faster Whenever

In our discussion of the pipelining technique we replaced

whenever private.parallelclient[1]->tostep2 do
     private.parallelclient[2]->[$name]($value)
whenever private.parallelclient[2]->tostep3 do
     private.parallelclient[3]->[$name]($value)

by

link private.parallelclient[1]->tostep2 to private.parallelclient[2]->*
link private.parallelclient[2]->tostep3 to private.parallelclient[3]->*

in order to bypass the Glish interpreter and send events quickly and directly between clients. You should be aware that replacing a whenever by a link in the above way can have a subtle impact on the way a large scale distributed application behaves.

This happens because direct communication between Glish clients is essentially synchronous. There is essentially no buffer space associated with a link (some tests show that there would appear to be a buffer size of 8192 words, but this is pretty well useless for applications sending a lot of data.) Glish clients also have one thread of control so they can only respond to incoming messages one at a time.

You will notice synchronized message passing in the following situation. If client a sends an event containing a large amount of directly to client b, client b transfers control to the callback function associated with this event and begins handling the data. If client b is finishes processing this data before client a sends the next data event, there is no problem. However if client a produces and sends the next data event before client b is finished processing the first one there is a problem. In this case client b is still processing data in the callback function, and it will not be able to immediately handle the event posted by client a at the moment client a posts the event. In this case client a blocks at the point it is trying to post the event. It cannot proceed further until client b finishes processing the data from the first event and returns to the event loop. So the rate at which client a can post messages to client b is limited by the rate at which client b can handle the messages. In a case where you might have four clients sending data along a pipeline, the rate at which each client in the pipeline will handle the data is directly dependent on the rate at which the slowest client can work.

The Glish interpreter behaves differently. If the Glish interpreter sends a message to a client, but that client is too busy to respond to the message, the Glish interpreter does not block, but remains responsive to other incoming events. It will attempt to do the write at some later time when the client becomes responsive. The interpreter behaves as a multi-threaded application stuck in a single thread.

So what this means is that if client a sends its events via a ``whenever'' to client b, the interpreter will store up the events it receives from a and will send them to client b at the rate client b can digest them. In this case client a may run to completion long before client b does. However if client a sends too many large data events to client b via the interpreter, the interpreter can essentially ``go out to lunch'' if it cannot get the events forwarded to and digested by the second client fast enough.

You can also recreate an illusion of asynchronous communication between two Glish clients that process data at different rates by putting a buffer client between the two tasks. The buffer client just contains a list. When the first client posts data it sends an event to the buffer task which just adds the data to one end of the list.

At the same time this buffer task could be observing the second task. When that task sends an event to the buffer task that it is available to process data the buffer task gets a data record off the other end of the list, deletes the element from the list, and posts the data to the second client. The list acts as a buffer between the two tasks. Of course, at some point, the faster task must stop generating data or you will run out of memory.