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 mpsc::Sender::closed future #2800

Closed
hawkw opened this issue Aug 28, 2020 · 1 comment
Closed

sync: add mpsc::Sender::closed future #2800

hawkw opened this issue Aug 28, 2020 · 1 comment
Assignees
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-sync Module: tokio/sync

Comments

@hawkw
Copy link
Member

hawkw commented Aug 28, 2020

Is your feature request related to a problem? Please describe.
Currently, the tokio::sync::watch channel has a Sender::closed async function. This can be awaited in order to notify a task when the receivers of that channel are all closed.

However, the mpsc channel's Sender type does not currently have such a function. This would be useful to add.

For an example use-case, see linkerd/linkerd2#4926. In essence, the intended use case is to prevent leaks of a task that sends messages over an MPSC channel by ensuring it is woken when the receiver ends of that channel are all gone. Currently, the sender can only become aware of the channel closing when it actually attempts to send a message. Although dropping the receivers would wake up the sender task if it is waiting to send a message (in the bounded MPSC), it won't be woken if it is waiting for some other work...but if there are no longer any receivers, that other work may no longer be necessary, and should be cancelled.

If we added a closed future, it would be possible to select over closed and some other work, so that the task is woken when the channel is closed and can proactively cancel itself.

Describe the solution you'd like

We should add a closed future, like the one on watch::Sender.

Describe alternatives you've considered
We could, alternatively, not do this. However, there isn't really any other good way to solve the problem that I can think of.

Additional context
Somewhat related: #2481

@hawkw hawkw added A-tokio Area: The main tokio crate M-sync Module: tokio/sync C-feature-request Category: A feature request. labels Aug 28, 2020
@hawkw hawkw self-assigned this Aug 28, 2020
zaharidichev added a commit to zaharidichev/tokio that referenced this issue Sep 17, 2020
Fixes: tokio-rs#2800

Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
zaharidichev added a commit to zaharidichev/tokio that referenced this issue Sep 23, 2020
Fixes: tokio-rs#2800

Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
zaharidichev added a commit to zaharidichev/tokio that referenced this issue Sep 23, 2020
Fixes: tokio-rs#2800

Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
zaharidichev added a commit to zaharidichev/tokio that referenced this issue Sep 24, 2020
Fixes: tokio-rs#2800

Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
zaharidichev added a commit to zaharidichev/tokio that referenced this issue Sep 25, 2020
Fixes: tokio-rs#2800

Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
@taiki-e
Copy link
Member

taiki-e commented Oct 5, 2020

Closing -- done in #2840

@taiki-e taiki-e closed this as completed Oct 5, 2020
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 C-feature-request Category: A feature request. M-sync Module: tokio/sync
Projects
None yet
Development

No branches or pull requests

2 participants