[e-lang] Consequences of transactional E?

[David Hopwood]

David Hopwood wrote:
> Kevin Reid wrote:
>>On Jan 30, 2007, at 1:13, David Hopwood wrote:
>>>Kevin Reid wrote:
>>>
>>>>   - Allow only Selfless objects to be carried by nonlocal exits.
>>>
>>>That is the solution I had intended [for exception objects].

Correction: I don't mean Selfless, I mean DeepSelfless. It's necessary that
no Selfish objects are reachable from the exception object.

This also applies to any other references that are communicated irreversibly
out of a transaction (i.e. regardless of whether the transaction rolls back).


In any case, I had thought based on
<https://sourceforge.net/tracker/index.php?func=detail&aid=1211106&group_id=75274&atid=551529>:

# (Once we have auditors, we will eventually allow E code to throw a Throwable
# containing any object that passes the DeepPassByCopy guard, ie, an object which
# is transitively PassByCopy.)

that the restriction to DeepSelfless would not be a problem, since DeepPassByCopy
implies DeepSelfless and DeepTransparent (see Figure 3 in
<http://www.erights.org/elang/kernel/auditors/>.

Previous discussion on how exception objects should be restricted:
<http://www.eros-os.org/pipermail/e-lang/2003-December/009374.html> and
<http://www.eros-os.org/pipermail/e-lang/2006-February/011112.html>.

> If you mean that the exception object could refer

... directly or indirectly ...

> to a Selfish object, I
> don't see how this could be given a safe and understandable semantics in
> a transactional model:
> 
>  - the Selfish object might no longer exist, because its creation has been
>    rolled back;
> 
>  - even if the object does exist, it is not safe to allow access to it after
>    the rollback, because its authority may have been granted only based on
>    conditions holding before the rollback that are no longer true.
>    (TOCTTOU with a vengeance -- the use is in a different "universe" to the
>    check.)
> 
> Referring to a

... transitively ...

> Selfless object is OK because such an object grants no authority,
> and is equivalent to a deep copy of itself. (Depending on the implementation,
> a deep copy *might* actually be needed, so there is also an implementability
> issue.)

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>