Ping-Pong examples

Additional information regarding the examples can be found in the Envy comment for the SstPingPong class. You can view the comment by selecting the button in the lower right of your Classes Browser. When the button is labeled Comment, you will see the Envy comments.

This example demonstrates by-value message passing. Regardless of the object you supply for @value, it will be passed as by-value and so will be local when printed. As such, it will print normally.

This example exercises by-reference message passing. The object supplied for @value will be passed as a value if it is immutable (for example, numbers, strings, and so on) but otherwise will go as a reference. The print-out should look the same as with by-value but more remote messages are required to get the printStrings.

Unlike the by-reference example, this example sends sstPrintString to @value rather than printString. sstPrintString never causes a remote message to be sent. If the receiver is a remote object, its object ID and home space are printed in {}s. Otherwise the object is printed normally. In one Transcript you should see @value printed normally and in the other it should come up as a reference shown in {}s.

This example demonstrates logical processes. This concept is described in detail in the SST manuals. To summarize, the LP model maintains standard Smalltalk process semantics across a set of distributed processes. Things such as out-of-scope returns, ifCurtailed: and ensure: block and process termination are done correctly even though a call chain may have ping-ponged in and out of various object spaces several times.

This first LP example shows that pings are always evaluated on the same process as are pongs. This may seem unsurprising but consider that when Ping pings Pong, it blocks waiting for a reply. In the meantime, Pong pongs Ping and yet this pong request is evaluated on the process which is blocked waiting for the reply. The content of @value does not play a particular role in this example.

This example demonstrates the termination of a logical process. In normal Smalltalk processes, an ifCurtailed: block is only run if the execution of the receiver block is aborted (for example, by an out of scope return or process termination). Here, when the ping-pong count runs out the current process is terminated causing the ping-pong chain to unwind but on the way back only the ifCurtailed: blocks are run. Notice that they are run in proper nested order. The content of @value does not play a particular role in this example.

Like the terminate example above, this example exercises LPs and ifCurtailed: blocks. In this case an out-of-scope return is evaluated at the end of the ping-pong chain. To do this, the example takes the user-supplied @value and wraps it in a block containing a method return (^). This block is the object passed along as @value when pinging and ponging. The finalAction evaluates @value and causes the return and then the ifCurtailed: blocks along the chain are run. The Transcript output shows that the ifCurtailed: blocks were run as expected.

The halt example is a variation of the unwind example above. Rather than passing along a block containing an out-of-scope return however, the halt example executes a self halt when it gets to the end of the ping-pong chain. Depending on the settings of the debugger, this causes a distributed debugger to be opened by the UI Handler (typically Ping). You can step, drop-to-frame and otherwise use the debugger as usual. You will note that some of the frames have [pong] appended to the end of their description (assuming the debugger is on Ping). This indicates that the frame is on a remote machine. One point of note is that dropping to a frame does not run the ifCurtailed: blocks between the current top and the drop point. This is standard Smalltalk behavior.

This example demonstrates the installation of the distributed garbage collection (DGC) system. This example is the same as SstPingPongLP except that on setup, a DGC object is created in each space. The DGC coordinator is assigned to pong. Note that the DGC is started immediately; this associates it with the application context for later retrieval. The total number of DGC collections performed is reported in the Transcript. Try running the example in the normal way using mutable objects for start:with:. For example, start: 3 with: #('a' 'b' 'c'). Run the example several times without doing cleanups. You will notice that the collection count slowly increases.

This example shows how the naming service is used with SST. The example uses by-reference message passing as in SstPingPongByReference. The differences are in how Ping obtains the remote reference to the factory object which creates the Pong object.

This example shows how Server Smalltalk can interoperate with Java using Java's Remote Method Invocation specification. In order to run this example you will need JDK 1.1.8 or later and the java code provide with the release. For more information on the Java RMI examples, please see Running the RMI examples.

The SstPingPongIiop examples demonstrate how to utilize the Iiop infrastructure provided with Server Smalltalk. To run these examples, you will need to insure the IDL for the ping pong examples is available. If you are using a full CORBA ORB implementation, than you can load the IDL directly into the interface repository. The IDL for ping pong is located in the Envy class comment of SstPingPong.

If you do not have an ORB you can still run the Ping Pong examples between two Server Smalltalk images. To do this, you will need to copy the file Ssidlicwpingpong.swp into your image directory on both Smalltalk images and rename it in both places to Sstidlic.swp. This file will allow SST to prime the repository cache with the standard Smalltalk bindings and the ping pong bindings.

IIOP PingPong examples fails with an object other than a String.
When running the IIOP PingPong examples you must pass a type that conforms to the CORBA Any type interface. Typically, Strings are used as the argument representing @anAnyType when sending the method SstPingPongIIOP>>start: @anInteger with: @anAnyType. Passing Smalltalk Integers and Floats as arguments will cause the example to fail because CORBA does not represent these as objects, and therefore, they do not conform to the Any interface.