binder: Invoke onTransportReady() in a round-robin fashion.#8835
binder: Invoke onTransportReady() in a round-robin fashion.#8835jdcormie merged 1 commit intogrpc:masterfrom jdcormie:flow-control-6
Conversation
Also call onTransportReady() only if isReady() still holds by the time we get to a given Inbound. This dramatically reduces timeouts and improves throughput when flow control has kicked in. This approach is still not completely fair since each ongoing call might consume a different amount of window on its turn, but because of the way Outbound#writeMessageData() and BlockPool already work, everyone gets to send at least 16kb.
|
nit: for changes like this it is helpful if the commit message would have a |
good point done. |
Yep thanks. The fact that ongoingCalls isn't navigable and can change between ACKs (and even while handleAcknowledgedBytes is running!) makes it tricky to do this using less memory per BinderTransport. With respect to fairness, in a future PR we could consider sending one 16kb Binder transaction per Outbound in round robin order to achieve completely fair (unweighted) queuing. It's just a more invasive change. Also isn't clear to me where the call to io.grpc.internal.StreamListener#onReady() would fit into this. |
|
Nice non-disruptive improvement! |
Also call onTransportReady() only if isReady() still holds by the time
we get to a given Inbound. This dramatically reduces timeouts and
improves throughput when flow control has kicked in.
This approach is still not completely fair since each ongoing call might
consume a different amount of window on its turn, but because of the way
Outbound#writeMessageData() and BlockPool already work, everyone gets to
send at least 16kb.
Fixes #8834