# Message sent to indicate that an embargo on a recently-resolved promise may now be lifted.## Embargos are used to enforce E-order in the presence of promise resolution. That is, if an# application makes two calls foo() and bar() on the same capability reference, in that order,# the calls should be delivered in the order in which they were made. But if foo() is called# on a promise, and that promise happens to resolve before bar() is called, then the two calls# may travel different paths over the network, and thus could arrive in the wrong order. In# this case, the call to `bar()` must be embargoed, and a `Disembargo` message must be sent along# the same path as `foo()` to ensure that the `Disembargo` arrives after `foo()`. Once the# `Disembargo` arrives, `bar()` can then be delivered.
--
You received this message because you are subscribed to the Google Groups "Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capnproto+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/E3F6C227-23BD-41E9-A4BA-A93EE4586C49%40mooseyard.com.
On Dec 17, 2022, at 1:46 PM, Kenton Varda <ken...@cloudflare.com> wrote:To clarify, when I say "Carol lives in Vat A, i.e. next to Alice", I am saying that Alice and Carol are two objects living in the same process. So a capability pointing to Carol was passed across the network and then back again, over the same connection.
Thanks. I then spent some time trying to figure out why this scenario occurs — when the local peer received the capability Carol from the remote one, shouldn’t it have been marked in the protocol as being a peer exported by the recipient?I think this can happen as follows; is this correct?0. I’ve already sent the capability Carol to the remote peer earlier in the connection, so the peer has a reference to Carol.1. I send an RPC call to acquire a remote capability, and allocate a (negative) remote capability # to it. Call it X. (I think this is what the protocol calls a promise?)2. Before the response arrives, I pipeline some more RPC calls addressed to X.3. I get a response to the first RPC call, identifying X as my capability Carol.At this point I can remap X to point to Carol, but I’ve already got some messages in flight addressed to remote capability X. I assume what happens to these is the peer just sends them back to me, substituting Carol for X, and then forwards my reply back to me? Thus the problem that I might send local messages to Carol that would arrive before the echoed messages to X even though I sent them later.
A different architectural solution to this problem might be for a peer to reject an incoming request addressed to a capability that isn’t local. Instead it would return an error indicating “X isn’t mine, it’s your Carol, so forward it there”.
But either way, isn’t there still a race condition if, in a new step 2.5, I send a message to local Carol? This message was sent after the message to X but arrives before I discover X is Carol, so it’s received out of order.
On Dec 26, 2022, at 3:28 PM, Kenton Varda <ken...@cloudflare.com> wrote:I'm not sure what you mean about "(negative) remote capability #". There are no negative numbers.