[e-lang] "io" vs "atomic" in E

[David Hopwood]

James Graves wrote:
> Rob Jellinghaus wrote:
> 
>>In several proposals for implementing transactional support in other 
>>languages, such as the recent Simon Peyton Jones work on integratign 
>>transactional support in Haskell as well as the current draft of the 
>>Fortress specification, two language constructs (or monads in the Haskell 
>>case) are proposed.  Call them "atomic" and "IO".
> 
> By the way, there's a nice interview of SPJ and Tim Harris talking about 
> STM over on MSDN:
> 
> http://channel9.msdn.com/Showpost.aspx?postid=231495

Thanks, that's interesting.

In their Java implementation, some exceptions cause rollback and others do not:

<http://research.microsoft.com/%7Etharris/>
<http://research.microsoft.com/%7Etharris/papers/2005-scp.pdf>

# The problem raised by exceptions is whether to undo updates made in the
# atomic block or whether to retain them and propagate the exception.
# Unfortunately there is a Catch-22 situation: if we roll back the updates
# then the exception object itself could be lost, leaving nothing to propagate
# (or worse, creating a dangling pointer if its allocation is rolled back).
# We discuss this in Section 3 and propose a hybrid model in which certain
# exceptions cause atomic blocks to be aborted and in which the exception
# thrown outside the block behaves as if it is a deep copy of the exception
# raised within it.

I don't think it is necessary to distinguish between different classes of
exceptions in this respect. Also, requiring the exception object to be (at
least) DeepSelfless means that a deep copy is equivalent to the original
object; in their approach, the deep copying is implemented by serialization,
and is observable.

(Note that implementing the copying by serialization requires them to be
able to run arbitrary Java code in custom serialization methods, which is
one of the reasons why they need to take a much more complicated approach
involving "external actions", as described in the paper.)

The "guard conditions" on atomic blocks aren't appropriate for an event-loop
language, because code within a turn should never block. The equivalent is
to use a when/catch, the body of which will run as a separate transaction
in its own turn. (In my proposal, the body will only run if the transaction
that posted it completes successfully.)

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