Re: how to extend a capability on a data source?

On Nov 3, 2013, at 1:44 PM, Rob Withers <[email protected]> wrote:

> I also thought a bit more about adding another object table reference - the question to the send.  If we allow sending to answers, then a message send to the answer id of the continuation, from the sender, could route back to the message send at evaluation vat, so we don’t need any change to Elib’s tables.   So that object ref is bi-directional and it "is" the message send.
> 
> Just allow a promise immediate access to the far ref to the executing msgSend (on top of the continuation id) and allow sending to that guy.  Hang event listeners off the redirector, so when an event fires through the continuation from the eval site, the send site can react.  I already have event registrations working, though not inserted into the redirector layer.  We will need to work out replication and failover semantics, and replication is coupled to vats and so also queues.

In thinking about this further, let’s try to lay it out. Has any other work been done in this sort of direction with message passing?  

I would like to add the last 3 bullets:
bi-directional message sending over the continuation
use continuation level event framework
register event listeners on 
the redirector (send)
any ref, resolved or otherwise
event firing:
all fired events of a ref go to all external references
event listener registrations have a mobile match function that are exported to the event source, to filter intelligently
make sends another subclass of refImpl
squash tumors, subjects that spew events, if the subject's ticket thresholdExceeded is crossed.  Issue a few thresholdWarnings, first.
All fired events of a ref (I guess we make the send a kind of ref), go to all external references to it through the connection scope/object tables.  Actually, we really want to add a real event listener, for any Object, to the target for any internalizing local ref, and the removal of the registration under internalization of a GCAnswer or GCExport.

Monitor event stats and threshold violation actions and call in the Cleaner, when appropriate, for spewing event sources.

So each MessageSend, with a resolver, would make 3 wire registrations in the scope:
the receiver (question or export)  observer —> subject
the promise (export)   observer —> msgSend result promise
the continuation (answer)  observer <—> msgSend
and events could flow back through the continuation.  Each MessageSendOneWay would only have the one receiver wire and would not be eventful.  No need to register a listener on sends queued in the vat that are one-way, is there?

Here’s my implementation of MessageSend, without the events or bi-directionality: https://github.com/reefedjib/murmur/blob/master/src/main/java/org/reefedjib/murmur/lib/vat/MessageSend.java

thanks,
rob

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk