[e-lang] "io" vs "atomic" in E (was: Consequences of transactional E?)

[Rob Jellinghaus]

Excellent discussion, I am very intrigued by David Hopwood's 
proposals.  MarkM and I had a brief phone conversation about a year ago 
regarding the relationships between transactional memory and E, but this 
takes it further.

In a language such as Erlang, all objects are essentially fully 
encapsulated and all object invocations are isolating.  In a language with 
transactional memory, all objects share state but message sends may occur 
within a transactional boundary, preserving state invariants in case of 
concurrent or erroneous plan violation.

A transactional event-loop language combines features of both:  each event 
loop or vat defines a boundary, with shared state consistency preserved 
(and protected from failing intra-boundary object invocations) 
transactionally within the boundary, and with message sends across the 
boundary providing state isolation.

One quick comment:

At 10:00 AM 1/29/2007, e-lang-request at mail.eros-os.org wrote:
>Date: Mon, 29 Jan 2007 10:55:04 -0500
>From: Kevin Reid <kpreid at mac.com>
>Subject: [e-lang] Consequences of transactional E? (was: Non-local
>         Exits vs        Defensive Consistency)
>To: Discussion of E and other capability languages
>         <e-lang at mail.eros-os.org>
>
>So. What are the consequences if we move E to this model? I've listed
>some below.
>
>1.
>
>As David Hopwood already pointed out:
>
> > It is, however, necessary to use a *pure* event-loop model for this
> > to work. E currently has some synchronous I/O facilities, which
> > would have to be reviewed and possibly removed.
>
>I would not mind this; to a certain degree E 'should have' been this
>way already.

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".

The "atomic" construct defines a nestable transactional boundary.  The "IO" 
construct defines a function that performs (synchronous) I/O.  The language 
ensures that IO constructs cannot be invoked from within atomic constructs, 
allowing transactional state rollback without needing to address issues of 
revoking completed I/O.

The same proposal would not entirely work within transactional E, because 
if a single vat permitted both IO constructs and atomic constructs (even if 
forbidding invoking IO constructs from atomic constructs within that vat), 
badly behaving IO constructs could violate defensive consistency for the 
entire vat.

This does suggest, however, that an *entire vat* could be defined as 
"atomic-safe" or "IO-unsafe".  Only "atomic-safe" vats would support full 
defensive consistency of (transactionally guarded) E code -- and would (of 
course) forbid all use of IO constructs within the entire vat.  "IO-unsafe" 
vats would not attempt to provide transactional safety guarantees, and 
would use the "terminate entire vat on exception" failure-handling policy, 
but would have access to synchronous I/O.

Whether "IO-unsafe" vats are too unsafe to be useful is a separate issue, 
but it does seem clear that they could interoperate with "atomic-safe" vats 
without violating the defensive consistency of those vats.

I'm not clear on whether this is worth doing, but it is at least worth 
mentioning :-)

Cheers!
Rob Jellinghaus