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

tokio: add mpsc::Receiver::max_capacity and mpsc::Receiver::capacity #6511

Merged
merged 3 commits into from May 3, 2024

Conversation

mbrobbel
Copy link
Contributor

Motivation

mpsc::Sender has max_capacity and capacity methods, however mpsc::Receiver does not. It may help to have these methods when trying to pre-allocate for Receiver::recv_many.

Solution

Adds Receiver::max_capacity and Receiver::capacity.

@github-actions github-actions bot added the R-loom-sync Run loom sync tests on this PR label Apr 23, 2024
@Darksonn Darksonn added A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Apr 23, 2024
@Darksonn
Copy link
Contributor

We already have an Receiver::len method. It was added in #6348.

@mbrobbel
Copy link
Contributor Author

mbrobbel commented Apr 23, 2024

We already have an Receiver::len method. It was added in #6348.

This is supposed to be an addition to that: capacity = max_capacity - len.

Comment on lines +563 to +565
pub fn capacity(&self) -> usize {
self.chan.semaphore().semaphore.available_permits()
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, this is not actually equal to max_capacity - len. Generally, sending a message goes through this procedure:

  1. Acquire a permit for the message.
  2. Write the message into the channel's storage.
  3. Make the message available to receivers.

With the len method, the length only changes in step 3, but with this method, the capacity already changes in step 1. If the user is using Permit to acquire permits before sending messages, then there may be a long amount of time between step 1 and step 2.

The documentation should clearly explain the difference.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've updated the example to explain the relation with Receiver::len. Is that sufficient?

Copy link
Contributor

@Darksonn Darksonn left a comment

Choose a reason for hiding this comment

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

Thank you.

@Darksonn Darksonn merged commit b7d4fba into tokio-rs:master May 3, 2024
76 checks passed
@mbrobbel mbrobbel deleted the sync/mpsc/receiver/capacity branch May 3, 2024 11:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate M-sync Module: tokio/sync R-loom-sync Run loom sync tests on this PR
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants