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

Add method mpsc::Receiver::is_closed #4638

Closed
Nugine opened this issue Apr 25, 2022 · 7 comments · Fixed by #6348
Closed

Add method mpsc::Receiver::is_closed #4638

Nugine opened this issue Apr 25, 2022 · 7 comments · Fixed by #6348
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. E-hard Call for participation: Experience needed to fix: Hard / a lot E-help-wanted Call for participation: Help is requested to fix this issue. M-sync Module: tokio/sync

Comments

@Nugine
Copy link

Nugine commented Apr 25, 2022

Is your feature request related to a problem? Please describe.

Describe the solution you'd like
Add a method to check whether the mpsc channel is closed from rx side.
mpsc::Receiver::is_closed
https://docs.rs/tokio/1.17.0/tokio/sync/mpsc/struct.Sender.html#method.is_closed

Describe alternatives you've considered

Additional context

@Nugine Nugine added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Apr 25, 2022
@Darksonn Darksonn added the M-sync Module: tokio/sync label Apr 25, 2022
@IanMichaelAsh
Copy link

Hi Nugine,

Please can you expand on your use case/scenario where having this method would provide a better solution than the existing mechanism of calling recv() and checking for None ?

Ian

@Darksonn
Copy link
Contributor

In general, I am ok with adding this assuming that it is easy to add.

@Nugine
Copy link
Author

Nugine commented Apr 26, 2022

I need to check whether a command channel is closed before trying to reconnect to a remote server.
I think it is easy to add because mpsc::Sender already has the method is_closed.

@IanMichaelAsh
Copy link

@Darksonn Obviously from your comment you can't be certain, but would your assumption lean toward most likely it is easy to add? I'd love to contribute to Tokio, so maybe this a good starting point, or would you point me elsewhere?

@Darksonn
Copy link
Contributor

My guess is that it is easy, yes. You're welcome to submit a PR for this. You might also want to look in the help wanted tag for easy ones, though note that the older ones might be outdated. If you have questions on how to approach writing the PR, you can ask in our discord server (or here).

@chipsenkbeil
Copy link

chipsenkbeil commented Sep 10, 2022

As a use case, I have a trait that implements reader and writer functionality similar to TcpStream, UnixStream, and the Windows client/server pipes. The trait provides try_write, try_read, and most importantly an equivalent to ready.

For one implementation, it uses mpsc Sender and Receiver.

It's easy to check if Interest::WRITEABLE will return Ready::WRITE_CLOSED or Ready::WRITEABLE by using tx.is_closed(). It's more difficult to check if Interest::READABLE will return Ready::READ_CLOSED or Ready::READABLE since there is no rx.is_closed(). Instead, I have to do rx.try_recv to check if the receiver is disconnected. If not and I receive data, I have to store this somewhere for future try_read calls.

@Darksonn Darksonn added E-help-wanted Call for participation: Help is requested to fix this issue. E-easy Call for participation: Experience needed to fix: Easy / not much labels Sep 11, 2022
@sanjayts
Copy link

I would be interested in picking this up -- this change seems more than just adding a single method so will be reaching out to you folks on Discord.

farnz added a commit to farnz/tokio that referenced this issue Sep 19, 2022
There's a use case for channels that wants to know up-front (before
calling `recv` or `try_recv`)that there's a possibility of new messages
coming in. Make it possible to check whether the channel is closed and
empty, which implies that there will never be new messages on this
channel.

Fixes: tokio-rs#4638
@Darksonn Darksonn added E-hard Call for participation: Experience needed to fix: Hard / a lot and removed E-easy Call for participation: Experience needed to fix: Easy / not much labels Sep 24, 2022
balliegojr added a commit to balliegojr/tokio that referenced this issue Feb 15, 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 C-feature-request Category: A feature request. E-hard Call for participation: Experience needed to fix: Hard / a lot E-help-wanted Call for participation: Help is requested to fix this issue. M-sync Module: tokio/sync
Projects
None yet
5 participants