Distributed Squeak and Environments

Anthony Hannan ajh18 at cornell.edu
Sat Jun 16 21:15:32 UTC 2001


I've been writing a distributed Squeak package that differs from the
previously mentioned remote-message-passing implementations in the following
ways:

1. Uses Image Segments
Image segments are transfered between images, instead of just the roots of
arguments and results, which helps reduce network traffic.  OutPointers
become remote references to the original image.

2. Remote Exception Handling and Block Returns
Processes wait for the remote message to finish and can receive and handle
exceptions signaled remotely.

3. Distributed Garbage Collection
Remotely referenced objects and their remote proxies are cached weakly on
both sides.  Finalization sends the free objects to the other image.

4. Environments for Version Control and Security
I'm still working on this but here is my proposal:

Every process has a working environment associated with it that is used to
look up global variables AND message selectors at runtime (instead of
compile time).  An environment can inherit from one or more static
environments (or packages).  When a message is sent to an object the
class-selector pair is looked up in the working environment and its
inherited environments in topological sort order (the specific order depends
on the order of the immediate parents).  If the pair is not found then the
superclass is paired with the selector and the environment graph is searched
again, and so on for each superclass.

Changesets can now be loaded as packages (environments) into any Squeak
system that already has the required prerequisites (inherited environments)
loaded.  When an environment is loaded it passes through a security filter
that may disable primitive methods and methods that directly access instance
variables or sensitive globals like #Smalltalk.  Runtime lookup of globals
and selectors allows different processes to see different isolated working
environments (or projects) at the same time.

When a new Squeak-to-Squeak connection is made each image loads the other's
working environment and then makes a new working environment for that
connection that inherits from both.  The order of the inheritance is server
environment then client environment, so execution will be the same no matter
which machine is actually executing.  This is important since objects move
across images when they become garbage in one image but are still referenced
in another.

Inherited environment values can not be changed, only overridden in the
working environment.  And values retrieved from static environments are
immutable, ie. classes and methods are immutable.  Changing a class
definition really defines a new class with the same name in the working
environment, where future references will find the new class before the old
one.


I'm still working on this and block closures so please stand by...
Cheers,
Anthony





More information about the Squeak-dev mailing list