[e-lang] Surprising consequences of pipelining?
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
A ahort description: An unresolved promise will behave as intended by
the holder of its resolver, *but not necessarily as intended by its
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