Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pd: use tokio_util::sync::PollSender in consensus svc #436

Merged
merged 1 commit into from Mar 2, 2022

Conversation

hawkw
Copy link
Collaborator

@hawkw hawkw commented Feb 15, 2022

In v0.7 of tokio-util, the PollSender API was changed to have the
semantics that most users expect (see tokio-rs/tokio#4214). The
poll_send_done method was replaced with a poll_reserve method, and
the implementation rewritten to drive a Sender::reserve_owned future
that's consumed in send_item. Now, PollSender essentially implements
exactly the same code that was written by hand in the consensus service.
We can simplify the consensus service significantly by upgrading the
tokio-util dependency to 0.7 and replacing the hand-written version
with PollSender.

There should be no functional change as a result of this refactor.

In v0.7 of `tokio-util`, the `PollSender` API was changed to have the
semantics that most users expect (see tokio-rs/tokio#4214). The
`poll_send_done` method was replaced with a `poll_reserve` method, and
the implementation rewritten to drive a `Sender::reserve_owned` future
that's consumed in `send_item`. Now, `PollSender` essentially implements
exactly the same code that was written by hand in the consensus service.
We can simplify the consensus service significantly by upgrading the
`tokio-util` dependency to 0.7 and replacing the hand-written version
with `PollSender`.

There should be no functional change as a result of this refactor.
Comment on lines 44 to +47
let span = req.create_span();
let (tx, rx) = oneshot::channel();

permit.send(Message {
req,
rsp_sender: tx,
span,
});
self.queue
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

we may want to check if the channel is closed here and bail early (in case it closed between a successful poll_ready call and the call to call). i don't know how that matters in pd, specifically, though, since there's only ever going to be a single consensus background worker and it's expected to live for the entire lifetime of the node...if it's gone, panicking in the send_item call is probably also fine.

I didn't change this because the previous code didn't have such a check.

@hdevalence hdevalence merged commit 90a9b3d into penumbra-zone:main Mar 2, 2022
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.

None yet

2 participants