Server Smalltalk Guide
The structure of the ping-pong examples highlights the setup, use and
properties of various SST configurations. You are encouraged to compare
the code for each and see how the various parts fit together and how
configuration variations change behavior. Below is a brief description
of each example and what you should expect to see when running it.
Similar text can be found the class comment for SstPingPong.
Note that the class SstPingPong is abstract and is not itself an
example.
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.
- SstPingPongByValue
- 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.
- SstPingPongByReference
- 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.
- SstPingPongLocation
- 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.
- SstPingPongLP
- 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 contents of @value does
not play a particular role in this example.
- SstPingPongLPTerminate
- 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
contents of @value does not play a particular role in this
example.
- SstPingPongLPUnwind
- 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.
- SstPingPongLPHalt
- 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.
- SstPingPongLPDgc
- 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.
- SstPingPongNamingService
- 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.
- SstPingPongRmi
- 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 and the java code provide
with the release. For more information on Java RMI support, please see
section ::section goes here::.
- SstPingPongIiop
- 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.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]