Path: news.daimi.aau.dk!poe
From: S|ren Brandt <sbrandt@daimi.aau.dk>
Newsgroups: comp.lang.beta
Subject: Re: Cloning of objects
Date: 11 May 1995 11:44:49 GMT
Organization: DAIMI, Computer Science Dept. at Aarhus University
Lines: 69
Approved: mailtonews@daimi.aau.dk
Distribution: world
Message-ID: <3ostbh$kc2@belfort.daimi.aau.dk>
NNTP-Posting-Host: daimi.daimi.aau.dk

> And I would like to stay with BETA.
> 
> Each process should have a method 'checkpoint' that checkpoints
> the total state of this process (including the execution stack
> of the component!) and returns a unique id. Using this id a 
> checkpointed state could be restored by a method 'rollback'. 
> Finally the process could be informed by a method 'cancel' that 
> a state associated with a given id is no longer needed. (This 
> looks a little bit like the persistent store [MIA 91-20], but
> of cause the state need not (should not!) be saved to secondary 
> storage and I fear that components (resp. execution stacks) are 
> not handled, are they? See [MIA 91-20], p.4, last paragraph.)

The basic mechanism employed by the persistentstore as well as the
distribution library to marshall objects is called "ObjectSerializer",
and can be found in "~beta/objectserver/v2.1/ObjectSerializer'". Check
it out, its my favourite library (I wrote it myself :-).

The ObjectSerializer mechanism could "easily" by employed to implement 
"in-memory-transactions". In fact this has been discussed and proposed 
as a suitable masters thesis project, although I don't know if anyone
has picked up the idea yet.

The problem with execution stacks is that they are not easily moved
between (OS) processes running at different hardware platforms, mainly
because we are not (currently) able to translate return addresses. But
to copy execution stacks "in-memory" is no problem, and I'm sure that
the Mjolner people or somebody at Aarhus would be interested in
providing the necessary basics to allow you to do so (I would like to
do so myself, but I'm leaving for Australia in three weeks from now).

> 
> If BETA would have a 'clone' operation -- which is currently 
> not available (see [Mad93] p.161) -- then it would be no problem 
> to implement an abstract super pattern 'process' with methods
> checkpoint, rollback and cancel. Of cause 'clone' would have to
> clone execution stacks of components, too.
> 
> (Leave out problems arising from cloning a component with a
> dynamic reference, letting the component destroy the object
> denoted by the dynamic reference while continuing execution, 
> an then rollback to a state where the object just destroyed 
> is assumed to be available... Perhaps all reachable objects
> (transitive closure) must be checkpointed, too, a la persitent
> store.)

In my opinion, the problem of what to checkpoint is a crucial one.
If you're not careful, you'll easily end up checkpointing way too much.

Personally I am currently developing a metaobject protocol for BETA,
on top of which functionality as the one discussed here can be
implemented in a portable way. If you're interested, I'll be able to
send you a copy of my report on the BETA metaobject protocol in a
couple of weeks. Notice however, that this is mainly a paper design,
and that implementation work will probably be suspended until I return
from Australia.

> 
> I think the problem is to make the access to the execution stack
> of a component more flexible than the one-way fashion 'first 
> attachment (creation), suspension, attachment, suspension,.., 
> last attachment, termination'. 
> 
> This is the crucial point, isn't it?

I don't think I get the point. Could you be a little more specific on
how you would use these more flexible primitives?

  -- Soren