Re: E Distributed Programming Clarification

On Sep 17, 2008, at 17:27, Jimmy Wylie Jr. wrote:

> What does the addExit method do and how is it relevant accomplishing  
> persistency in distributed programming?


An exit, in persistence, is a place where the object graph is cut, and  
rejoined later, to something equivalent to the previous thing.

Suppose we have a mutable object of some sort:

   def listOfInterestingThings := [].diverge()

Consider what happens if we serialize some object referring to this  
object; let's just use a list (but this is equally applicable to any  
serializable object whatsoever)

   [1, 2, 3, listOfInterestingThings]

If we just serialize this list, then its serialized representation  
will be

   "[1, 2, 3, [<current contents>].diverge()]"

and when we unserialize it later, it will have its own copy of  
listOfInterestingThings as of when it was serialized -- not shared  
with anything else.

If, instead, we add an exit for listOfInterestingThings, then the  
serialized form is

   "[1, 2, 3, listOfInterestingThings]"

which, upon unserialization, will be reconnected with the presumably  
already-existing mutable list.

Another major case is external authorities. For example, <file>, the  
access to the local filesystem, is an exit: when you serialize a file  
object, what you get is an instruction to reconstruct it from <file>  
and the pathname.

(I believe the chatReceiver is similar to the first two cases, but I  
haven't looked at the code.)

Thirdly, we have object makers: for example, whenever you serialize a  
list, or a map, the serialized form contains a mention of  
makeConstList or makeConstMap; these are exits.

In general, exits are used for things that can't or shouldn't be  
serialized, but rather replaced with "equivalent" things from the next  
incarnation of the vat.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>