Skip to content

fixed #686 - make channel confirmations truly async - #723

Merged
Eugeny merged 2 commits into
mainfrom
686-async-channel-confirm
Jun 6, 2026
Merged

fixed #686 - make channel confirmations truly async#723
Eugeny merged 2 commits into
mainfrom
686-async-channel-confirm

Conversation

@Eugeny

@Eugeny Eugeny commented Jun 5, 2026

Copy link
Copy Markdown
Owner

No description provided.

@Eugeny
Eugeny marked this pull request as ready for review June 6, 2026 19:38
@Eugeny
Eugeny merged commit c1f8141 into main Jun 6, 2026
11 checks passed
@Eugeny
Eugeny deleted the 686-async-channel-confirm branch June 6, 2026 19:54
EpicEric added a commit to EpicEric/russh that referenced this pull request Jul 6, 2026
Before Eugeny#723, synchronous channel acceptance/rejection would happen regardless of
message dispatch. Now, the channel reply uses the same bounded mpsc channel
that the handler consumes from.

However, under contention (for example, with multiple simultaneous channels
opening and writing over the same handler), the awaits in
`ChannelOpenHandleInner::accept` and `ChannelOpenHandleInner::reject` may
hang while the consumer is the handler itself, thus leading to a self-deadlock.

This PR changes channel confirmation to use its own unbounded channel on
both server and client implementations, avoiding any awaits (since send
is sync), and thus, any deadlocks under load.

Because of the change to `ChannelOpenHandleInner::accept` and
`ChannelOpenHandleInner::reject` into sync methods, this is
backwards-incompatible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant