[e-lang] Surprising consequences of pipelining?

Kevin Reid kpreid at attglobal.net
Fri Jul 1 23:28:40 EDT 2005

Consider this code:

   def coerced := (def guard := thing <- __getAllegedType()) <- 

If I understand pipelining correctly, since the 'coerce' message is 
sent to a promise whose tail is in 'thing''s vat, that vat has the 
opportunity to respond arbitrarily to it - and then resolve 'guard' to 
a completely unrelated object!

It seems quite natural to assume that, given the above code, if 'guard' 
resolves to an already-known guard, then 'coerced' has passed that 
guard's coercion; but this does not hold given pipelining.

Is there some reason this cannot happen, or an obvious reason for an E 
programmer to not expect the above code to function as intended? Have I 
forgotten somewhere that this is documented?

The rest of this message assumes that this problem does exist as I have 
described it.

A ahort description: An unresolved promise will behave as intended by 
the holder of its resolver, *but not necessarily as intended by its 
future resolution*.

Things that could be done:

   1. Throw out pipelining.

   2. Make any given inter-vat promise never resolve to being the same 
as another reference. This prevents programs from being able to have 
expectations of past behavior based on sameness tests of the 
resolution; they must always assume that there might be a transparent 
forwarder. This would also make it impossible to pass PassByCopy 
objects except as message arguments; they would otherwise have to be 
passed as if PassByProxy.

   3a. Make available in the safeScope an operation for responding to 
the eventual sends to a promise before that promise is resolved. This 
restores the property that "a malicious vat hosting one set of objects 
can only cause external effects equivalent to a correct vat hosting 
some different (maliciously coded) set of objects" (from 

   3b. Add support for unprivileged comm systems.

   3. 3a and 3b are different descriptions of approximately the same 
change. Ideally, having 3b, specifically documented as being a means 
for 3a, would remind the programmer that they cannot rely on 
pre-resolution behavior to correspond to post-resolution identity.

Kevin Reid                            <http://homepage.mac.com/kpreid/>

More information about the e-lang mailing list