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

sync: add len and is_empty methods to mpsc senders #7103

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

tqwewe
Copy link

@tqwewe tqwewe commented Jan 15, 2025

Motivation

Closes #7077

Tldr; adds len and is_empty methods to both bounded and unbounded Senders.

Solution

@conradludgate mentioned in the issue in a comment that the unbounded len can be derived from the seamphore's available permits / 2. However it seems like I didn't need to divide the semaphore available permits based on tests.

The implementation of len for bounded Sender did not use the semaphore's available permits directly, and instead used the semaphore's bound - available_permits.

I've added tests for these new methods which are passing.


Related PR #7092

@github-actions github-actions bot added the R-loom-sync Run loom sync tests on this PR label Jan 15, 2025
@maminrayej maminrayej added A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Jan 16, 2025
tokio/src/sync/mpsc/bounded.rs Outdated Show resolved Hide resolved
Comment on lines +1098 to +1100
pub fn len(&self) -> usize {
self.chan.semaphore().bound - 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.

Unfortunately, this seems incorrect to me. This will include permits in the count, but to match the receiver length method, permits should not be counted.

Copy link
Author

Choose a reason for hiding this comment

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

Hmm true, I've updated the test locally and it does seem to be affected by reserved permits. I am not well versed in the internals of tokio, but it seems like the length may not be able to be derived from the bounded sender as is due to this reserved permits issue? I'd like to be wrong, but if not then perhaps it would require an atomic counter added to keep track of reserved permits vs messages?

Copy link
Contributor

Choose a reason for hiding this comment

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

I believe I commented on this issue previously: #6314 (comment)

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.

Add .len() method to UnboundedSender
4 participants