icerpc-csharp Leader-follower in icerpc accept loop?

I am wondering if we could/should switch to a leader-follower model in the icerpc AcceptRequestsAsync loop: https://github.com/icerpc/icerpc-csharp/blob/6036d786a0ad5ee1f81bc6b5c0ae469db7c12125/src/IceRpc/Internal/IceRpcProtocolConnection.cs#L892

Currently, we have a task that accepts new requests (= multiplexed streams) and then schedules their dispatch in a separate thread: https://github.com/icerpc/icerpc-csharp/blob/6036d786a0ad5ee1f81bc6b5c0ae469db7c12125/src/IceRpc/Internal/IceRpcProtocolConnection.cs#L953

The alternative would be for the thread that accepted the stream to perform this dispatch. And before dispatching, it would schedule (Task.Run) another AcceptRequestAsync (singular).

The potential advantage here is better latency since there is one fewer context switch.

If you look at Slic, the implementation of AcceptStreamAsync already performs a context switch: the Slic reader thread/task pushes the new stream into a Channel (_acceptStreamChannel), and AcceptStreamAsync pulls from this channel not inline. (I think this Slic logic is fine).

May 29 '23 18:05 bernardnormier

I implemented leader-follower with MultiplexedConnectionRps (not difficult, just need a helper TCS). I could not see a difference for coloc on Windows.

Jun 01 '23 23:06 bernardnormier

leader-follower is not a good idea. The current setup (with a single read flow) is much simpler.

Jul 30 '24 14:07 bernardnormier