Skip to content

Conversation

@eminence
Copy link
Contributor

Clarify at the connection is always closed when accept returns, and that the AcceptError variant doesn't really matter

/// The returned future runs on a freshly spawned tokio task so it can be long-running.
/// The returned future runs on a freshly spawned tokio task so it can be long-running. Once
/// `accept()` returns, the connection is closed, so the returned future is expected
/// to drive the protocol to completion. If there in a protocol error, you can
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo is a

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should also clarify that the connection is only closed if no other clones exist, not alwayy when accept returns. I.e. if you send the connection or a clone to another task via a channel and return from accept, the connection will stay alive until closed explicitly by user code with Connection::close or until the last clone of Connection is dropped.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good comment, thanks. I just force-pushed a new version that does a better job with this

Clarify at the connection is always dropped when `accept` returns, and
that the AcceptError variant doesn't really matter
@eminence eminence force-pushed the protocol_handler_docs branch from 33b7033 to 2a65d09 Compare October 23, 2025 23:13
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.

3 participants