[e-lang] CapTP in E progress report #5
kpreid at mac.com
Mon Aug 13 12:46:59 EDT 2007
Sorry for the long delay since the last report. I tend to not get
around to writing about what I'm working on.
- Serialization/reference passing: (r864) <import>.optUncall now
works for more kinds of non-emaker imports. (r867) Broken references
are now passed by construction. (r869) Incoming ImportDesc(0) is
implemented. (r870) Type/Message/ParamDescs now meet the requirements
- (r868) The basic CapTP connection tests now create a new connection
for each category of tests, reducing unnecessary state sharing (and
therefore spurious revisions to keep conceptually independent
sections in sync).
- (r871-872) I added a pipelined send example, and fixed time-of-
unserialization bugs in the test revealed by it.
- (r873) Fixed: NewRemotePromiseDesc failed to place the promise in
the imports table.
- (r876) The Introducer object has been roughly sketched out; it
isn't hooked up to anything else yet.
- (r874, 877) Translated LocatorUnum and made it an exit so it
behaves as an unum.
- (r882) The high-level CapTP message representation has been
revised. Previously, a connection's incoming message interface
consisted of a "receiver", which accepts E messages corresponding to
CapTP messages, and a "builder maker", which provides Data-E builders
to be used for the serialized-object arguments in CapTP messages. I
have now changed this so the builder maker is not exposed, and the
object arguments are instead represented as functions (defined by the
caller) which accept a builder and return the builder's result (i.e.
they are closures over some Data-E recognizer). This interface allows
the recipient of a CapTP message to control the timing of
unserialization, making implementation much simpler (especially for
the wire protocol serializer).
The next component is the wire protocol (un)serializer. This is what
serializer <- GCExport(1, 2)
into [10, 0, 0, 0, 1, 2] and delivers it to some encrypted message
stream. The basic logic of it is done; I'm currently working on
designing the 'proper' E/EIO-style replacement for java.io.Data
An issue that had been raised is: what does a passed disconnected ref
I find that under the mechanisms my ELib provides, passing a
disconnected ref necessarily results in an unconnected ref, because
the proxy->disconnected transition discards the proxy handler (so
Ref.optSealedDispatch can't be used on it to retrieve the original
identity); furthermore, this is the simplest thing for an uncaller to
implement (testing with Ref.isBroken or similar).
I think this is not too unreasonable behavior. For one thing,
attempting to preserve the unconnected ref's identity would, given
non-transitive network failures, result in a disconnected ref
possibly arriving as a far (non-broken) ref.
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang