Re: RFC: StepTalk semi-persistent shared environment(s)

[Quentin Mathé]

Le 19 août 05 à 17:49, Stefan Urbanek a écrit :

Hi,

As I have access to the interned again, I would like to share some news.

I have implemented a prototype of StepTalk semi-persistent shared

environment.

Hi Stefan,

Sorry for the late reply…

** Questions

Following are several questions regarding the new addition to the

StepTalk. I would like to hear your opinion.

1. naming questions

- is the name STDistantConversation right?

I'm not convinced I must say, why not STDistantEnvironment ?

- interpretScript:inEnvironment or interpretScript:environment?

interpretScript:inEnvironment

- methodFromSource:forReceiver:inContext: or

methodFromSource:receiver:context:

methodFromSource:receiver:context or methodForSource:receiver:context could be better.

2. reference or copy?

- what should be default: returning result by reference or by copy? that

is, the method -result should return reference or copy? if reference,

then there would be following pair:

   - result

   - resultByCopy (or copyOfResult?)

otherwise there would be following pair:

   - result

   - resultByReference

Or - resulByCopy:(BOOL)flag?

- result

- resultByCopy

looks right in my opinion. I wouldn't use copyOfResult.

3. Passing object there and back

- How to pass objects to the distant environment?  Problem is simple:

what if I pass an object by reference to the environment and I will die?

One suggestion is, that user will be allowed to pass a dictionary bycopy

to the conversation on the environment process side with some simple

variables only. However, that should be only a temporary solution before

a more complex solution would be found.

copy-on-die ;-)

I mean, each object would have a unique id assigned when it is shared between two or more environments, and when parent environment (which provided the object initially) terminates, the object would be copied to the first distant environment which obtained a reference on it. 

With more details, it may look like :

-> an object starts to be shared between a parent environment and a distant environment

- a unique id is created (probably stored in an ivar by extending STObjectReference ?)

- an environments array is created with 'parent environment', 'distant environment' (probably stored in an ivar by extending STObjectReference ?)

- the object reference is put in a persistent hash table (id is playing hash role)

Note: the persistent hash table could be a light key/value database like SkipDB <http://www.dekorte.com/projects/opensource/SkipDB/>

-> a shared object stops to be used in a distant environment

- the distant environment removes itself in 'environments' array

- it removes the object in hash table if 'environments' array is now empty (reference count inspired mechanism)

-> the parent environment terminates

- the parent environment checks every shared objects presence in hash table by iterating over their id (I'm supposing each environment have a way to know which local objects are shared)

- if the object is referenced by the hash table, it is copied to the second environment referenced in 'environments' array, then dying environment removes itself in 'environments' array

- otherwise, the object is deallocated.

Finally environment loading could be extended with a mechamism to check STObjectReference objects state :

- the environment checks the persistent hash table to know if the object is referenced or not

- if the object is referenced, it retrieves STObjectReference object for it (previously stored)

- otherwise a blank object reference is created

A similar mechanism is used in Io language to implement orthogonal persistency iirc.

- How to get objects from the distant environment? At the moment, there

is only one way how to get them and that is to execute a script that

returns required object and get it using - result (either by reference

or by copy). Thing is, that at the moment context of distant

conversation is not available. When it would be available, then what

methods should be provided and with what restrictions? (see STContext.h

and STEnvironment.h)

Any STObjectReference may have a method -sharable which returns NO by default, but a -setSharable accessor would allow to set it to YES.

And objects when put in context/environment dictionary would automatically returns YES to this method.

Why not try to solve this question with the previous one ?

3. Should be creation of the distant environment (launching new

stenvironment process) included in the framework? If yes, then how?

Separate class? *Manager or *Server or something else?

EnvironmentManager class ?

4. What is the best way to terminate a distributed objects server?

I don't know.

5. How would you expect termination of the environment process to be

handled?

- Can it be allowed from a script or programatically from conversation

only?

I would say both.

- If from script, then how? 'Environment close' or 'Environment

suicide' (analogy to external KILL signal, that is, KILL to self)?

Environment terminate

Quentin.

--

Quentin Mathé

qmathe@club-internet.fr