liveslots should expose sendOnly functionality to vat userspace code

[warner]

What is the Problem Being Solved?

Messages sent through the SwingSet kernel have an optional result parameter, which identifies the promise that should be resolved with the results of delivering the message. Our usual p = E(target).method(args) syntax returns a javascript Promise which is allocated a vpid (vat-side promise identifier), and that vpid is included as the result of a syscall.send.

Messages which lack a result are "send only": the sender is not informed about the results in any way (not even if the message is sent to a dead vat). When appropriate, this is more efficient, because we don't need to allocate/track/resolve a result promise identifier.

Liveslots doesn't currently expose a way to do "send only" to userspace. #1865 added E.sendOnly() support to @agoric/eventual-send, so that's the preferred thing to call, but I don't think liveslots knows how to handle this any differently than a regular result-bearing E() call.

We'd especially like to use this in the vattp vat, which is a regular liveslots-based vat, but wants to send unidirectional sendOnly messages into the comms vat.

Description of the Design

I think this will involve changing the fulfilledHandler in makeImportedPresence() to have more than just the applyMethod property, maybe an applyMethodOnly one. Likewise for the unfulfilledHandler in makeImportedPromise(). Maybe this should call queueMessage too, but with returnedP=undefined. We also need to change queueMessage to realize when it's getting an empty returnedP and not attempt to register it in valToSlot/slotToVal.

@michaelfig does that sound right? The best docs I've been able to find are https://github.com/tc39/proposal-eventual-send , and they talk about handler traps for sendOnly, but the names they use (eventualSend/eventualSendOnly) don't match the applyMethod that we're using in liveslots right now. I can dig into the @agoric/eventual-send code if that's a better source of truth.

Security Considerations

This won't increase the authority available to user code. Using sendOnly has a different set of debugging properties than a normal send: if something breaks, you won't hear about it, and unless we have a usable way to record/publish/reveal all exceptions that occur during message sends, nobody else will hear about it either. It is frequently better to log-and-ignore the error than to do a real sendOnly, so a developer can at least have a chance to discover a coding error. But if the message recipient takes responsibility for log-and-ignore, perhaps at the top level of the receiving object, then sendOnly can be appropriate.

Test Plan

regular unit tests

[michaelfig]

@michaelfig does that sound right? The best docs I've been able to find are https://github.com/tc39/proposal-eventual-send , and they talk about handler traps for sendOnly, but the names they use (eventualSend/eventualSendOnly) don't match the applyMethod that we're using in liveslots right now. I can dig into the @agoric/eventual-send code if that's a better source of truth.

It depends how soon you need it. The proposal-eventual-send needs some work and there will be an API change (likely Promise.delegated instead of HandledPromise), so this could wait for a flag day if you don't have any urgency.

If you have a specific use case, you're welcome to propose something based on @agoric/eventual-send and I'd be happy to review (i.e. make minor tweaks to) a PR that goes in this direction.

[warner]

@michaelfig has anything changed on the eventual-send side since then? I'd like to implement something on this soon.

[michaelfig]

@michaelfig has anything changed on the eventual-send side since then? I'd like to implement something on this soon.

No change. You can use E.sendOnly(x)... to indicate your intent, but it doesn't do less work on the promise handler side yet.

[warner]

Incidentally, the primary use case for this is to allow vat-vattp to stop creating a result promise for the E(commsReceiver).receive(msg) messages it sends to vat-comms, which would save one dispatch.notify delivery per inbound message. This extra delivery consumes 30-40% of the total vattp time (29ks out of 69ks of runtime over the testnet4.5 corpus), although that's kinda warped because of the #3839 leak).

I don't expect much userspace to take advantage of sendOnly; it's too easy to let errors fall through the cracks that way.