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

Support peek() for mpsc::Receiver #6965

Open
shade opened this issue Nov 9, 2024 · 3 comments
Open

Support peek() for mpsc::Receiver #6965

shade opened this issue Nov 9, 2024 · 3 comments
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-sync Module: tokio/sync

Comments

@shade
Copy link
Contributor

shade commented Nov 9, 2024

Is your feature request related to a problem? Please describe.
I have an application that needs to wait for a value to show up in a channel within a certain time-frame before running some business logic.

Describe the solution you'd like
The ideal solution would be to have a async peek() functionality which is ready when a value has been sent but does not consume the value.

let (sender, receiver) = mpsc::channel(10);

timeout(receiver.peek(), TIMEOUT).await?;

// Hand off the receiver to some task to process all the value.
business_logic_task(receiver);

Describe alternatives you've considered
Alternative 1. Is to await on recv() and write our business logic to work with the first channel value as a special case.

Alternative 2. Is to wrap the Receiver in a ReceiverStream, convert it into a Peekable stream and call peek on that.

My main gripe is that after the conversion to Peekable, we cannot get the original receiver back as we have a lot of logic that depends on Receiver type and we will have to change this to be Peekable or worse, a generic Stream.

@shade shade added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Nov 9, 2024
@shade
Copy link
Contributor Author

shade commented Nov 9, 2024

FWIW, I'm happy to write out the PR. But would like to know if there's any strong objection before doing so.

@Darksonn Darksonn added the M-sync Module: tokio/sync label Nov 10, 2024
@Darksonn
Copy link
Contributor

My initial reaction is that I don't love this feature request.

It sounds like you don't actually need peek to return the value?

@shade
Copy link
Contributor Author

shade commented Nov 10, 2024

It sounds like you don't actually need peek to return the value?

Indeed, we just want a notification that the receiver is ready to be recv()-d or try_recv()-d without consumption of any values. Maybe async fn ready() would be a better?

Also, seems like some other folks have been asking for similar feature as well hence the peek idea:

Would be curious to understand any objections you may have :)

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