Hi Kenton,
Thank you for your quick response! It's very helpful because the handler
for the disconnection is another issue actually.
On Tuesday, November 23, 2021 at 1:53:42 AM UTC+9 ken...@cloudflare.com
wrote:
> Hi Mitsuo,
>
> I recommend designing the interface like this:
>
> interface
Quoting Kenton Varda (2021-11-23 19:20:50)
>On Tue, Nov 23, 2021 at 5:01 PM Ian Denhardt <[1]i...@zenhack.net>
>wrote:
>
> Ok, I think I get it, let me know if I have this right:
> [...]
>
>Right.
Ok, great. Thanks for your patience.
> Cap'n Proto doesn't provide any
On Tue, Nov 23, 2021 at 5:01 PM Ian Denhardt wrote:
> Ok, I think I get it, let me know if I have this right:
>
> The correct thing to do is to handle congestion/flow control for
> multiple calls on each object individually, using something like
> the mechanisms provided by the C++
Ok, I think I get it, let me know if I have this right:
The correct thing to do is to handle congestion/flow control for
multiple calls on each object individually, using something like
the mechanisms provided by the C++ implementiation's streaming
construct. This is important so that calls on
On Tue, Nov 23, 2021 at 3:59 PM Ian Denhardt wrote:
> What are apps *supposed* to do here? It isn't clear to me where else the
> backpressure is supposed to come from?
>
Apps should cap the number of write()s they have in-flight at once. (`->
stream` helps a lot with this, as it'll
(Adding Louis to cc per his request)
Quoting Kenton Varda (2021-11-23 14:50:20)
>On Tue, Nov 23, 2021 at 12:41 PM Ian Denhardt <[1]i...@zenhack.net>
>wrote:
>
> Wouldn't releasing it on return allow the caller to cause runaway
> memory
> usage by just never sending the
On Tue, Nov 23, 2021 at 12:41 PM Ian Denhardt wrote:
> Wouldn't releasing it on return allow the caller to cause runaway memory
> usage by just never sending the finish? the return entry needs to be kept
> around in case calls are pipelined on it, and itself might take up some
> space (arguably
Quoting Kenton Varda (2021-11-23 13:02:32)
>Hmm, I think the intention was that the flow limit should be released
>on Return, independent of Finish. But I can totally believe I
>implemented it wrong. Could we just change it to be based on Return?
>FWIW by default there is no flow
Hmm, I think the intention was that the flow limit should be released on
Return, independent of Finish. But I can totally believe I implemented it
wrong. Could we just change it to be based on Return?
FWIW by default there is no flow limit, it's only enabled in the Sandstorm
supervisor to defend
Hey all,
A few days ago one of my co-maintainers (Louis) alerted me to a deadlock
in the Go implementation. We've pinned down the cause, and while trying
to figure out how to fix it, I looked into how the C++ implementation
handles backpressure.
>From what I can tell, the only way backpressure
10 matches
Mail list logo
