Skip to content

sync: add sender_weak_count and sender_strong_count for Receiver#6661

Merged
wathenjiang merged 2 commits intotokio-rs:masterfrom
0xPoe:rustin-patch-Receiver
Jul 2, 2024
Merged

sync: add sender_weak_count and sender_strong_count for Receiver#6661
wathenjiang merged 2 commits intotokio-rs:masterfrom
0xPoe:rustin-patch-Receiver

Conversation

@0xPoe
Copy link
Copy Markdown
Contributor

@0xPoe 0xPoe commented Jun 27, 2024

Motivation

close #6653

Solution

Added sender_weak_count and sender_strong_count for Receiver and UnboundedReceiver.

@github-actions github-actions bot added the R-loom-sync Run loom sync tests on this PR label Jun 27, 2024
Copy link
Copy Markdown
Contributor Author

@0xPoe 0xPoe left a comment

Choose a reason for hiding this comment

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

🔢 Self-check (PR reviewed by myself and ready for feedback.)

}

pub(super) fn weak_count(&self) -> usize {
self.inner.tx_weak_count.load(Relaxed)
Copy link
Copy Markdown

@randomairborne randomairborne Jun 27, 2024

Choose a reason for hiding this comment

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

Why Relaxed here? Wouldn't Acquire be appropriate?
(I am curious, not saying you're wrong)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

It looks like this is just mirroring the orderings on the equivalent sender methods. I don't think it really matters.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The main difference between them as I understand it is that with tx_weak_count, it's simply a counter. So it doesn't matter what order it's in.
But with tx_count we rely on it to decide whether to close the channel or not, in addition to counting the number, and it's more of a synchronized operation, where we have to make sure that there is a guaranteed ordering of operations on it between threads.
I'm not sure if I'm right about this, I could be completely wrong 😆

@Darksonn Darksonn added A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Jun 30, 2024
0xPoe added 2 commits July 1, 2024 19:18
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
@0xPoe 0xPoe force-pushed the rustin-patch-Receiver branch from cace970 to 954858c Compare July 1, 2024 11:18
@0xPoe 0xPoe changed the title sync: add weak_count and strong_count for Receiver sync: add sender_weak_count and sender_strong_count for Receiver Jul 1, 2024
@0xPoe 0xPoe requested a review from Darksonn July 1, 2024 12:14
Copy link
Copy Markdown
Contributor

@wathenjiang wathenjiang left a comment

Choose a reason for hiding this comment

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

LGTM. Thanks!

@wathenjiang wathenjiang merged commit fe7285d into tokio-rs:master Jul 2, 2024
@0xPoe 0xPoe deleted the rustin-patch-Receiver branch July 2, 2024 23:56
This was referenced Jul 22, 2024
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.

Get mpsc::Sender count on mpsc::Receiver

4 participants