Callbacks, cancellation and EOF with ByteStreams

[Vaci]

If a capability accepts a callback as a method param, such as for subscriptions, then it seems there are (at least) two possible ways to handle cancellation:

a) return a handle that can be dropped to cancel the subscription

interface Foo {

  subscribe (callback :Callback) -> (handle :Capability);

}

or b)

fulfil the promise returned by the method call at EOF, and drop the promise to cancel the subscription.

interface Foo {

  subscribe (callback :Callback);

}

I'm curious to understand fully the pros and cons of each approach, especially when the callback is a ByteStream, where it seems natural to return the pumpTo promise as the result of the subscribe call's implementation?

Cheers,

Vaci

[Kenton Varda]

The promise approach is more elegant and efficient. Historically it has sometimes led to complications, though. Particularly tricky is bidirectional streaming.

    subscribe(downstream :Downstream) -> (upstream :Upstream)

The problem here is that all messages sent to `upstream` will normally be held until `subscribe()` itself returns a capability which they can be sent to. So if `subscribe()` doesn't return until the downstream direction is done (or canceled), then the upstream doesn't work.

HOWEVER, if you're using the C++ implementation, a solution to this was introduced two or so years ago. You can use `context.setPipeline()` to connect the pipelined capabilities without actually completing the RPC.

So, assuming you can rely on `setPipeline()` being available, then I would lean towards the promise approach rather than the handle approach.

-Kenton

--
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/790ea1e0-65e6-44e1-a97a-93e943dd8b34n%40googlegroups.com.

[Vaci]

Hi Kenton,

That makes sense, thank you!

A theoretical point perhaps is that one might want to keep the handl alive by passing it to another longer-lived VAT, whereas the lifetime of a promise is bound by the VAT it's running in.

Vaci

[Kenton Varda]

Today, without three-party handoff, you could always wrap the promise in a capability and send that. But, yes, this involves a proxy step that 3PH won't be able to optimize away later... at least not under the current design.

-Kenton

To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/026806ab-0704-46ec-8b30-5101adb882a9n%40googlegroups.com.