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.

Sign up for GitHub

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

Jump to bottom

sync: Update broadcast::recv to return a named future #6908

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

sync: Update broadcast::recv to return a named future #6908

wants to merge 1 commit into from
+36 −11

Conversation

jplatte
Copy link
Member

@jplatte jplatte commented Oct 17, 2024 •
edited
Loading

Motivation

Closes #6902.

Solution

I only made the minimal change of adding the public Recv future type.

I also briefly looked into updating tokio_stream::wrappers::BroadcastStream to not use ReusableBoxFuture, but it's not as easy as I had hoped as it owns the underlying receiver while borrowing it when being polled - i.e. it's self-referential which is only possible with async fn or some extra unsafe code.

For my main use case for this though (in my own crate), the unsafe code + impl !Unpin is likely preferable over the hack I shared in the issue linked above. I don't know whether the same applies to tokio-stream.

@jplatte jplatte added A-tokio Area: The main tokio crate M-sync Module: tokio/sync labels Oct 17, 2024
@github-actions github-actions bot added the R-loom-sync Run loom sync tests on this PR label Oct 17, 2024
@Darksonn
Copy link
Contributor

Are you sure this actually allows you to solve #6902? The stream is still going to need to be self-referential.

@jplatte
Copy link
Member Author

jplatte commented Oct 18, 2024

Well, I think it helps. My current plan for my downstream crate is to write a self-referential RecvOwned based on this by hand with unsafe - that seems less awkward to me than the previous workaround. Would that be something you would accept into tokio-stream as well (I guess if it was there, I could depend on tokio-stream in my downstream crate too)?

I can also think of two alternatives:

  • Introduce NonSendReusableBoxFuture in tokio-util (the unsafe c'tor for ReusableBoxFuture seems much more risky to me, I tried something), use the same workaround as now but without copy-pasted code downstream
  • Not sure whether it's possible, but I think it would be: Add Receiver::recv_owned(self) -> RecvOwned<T>, impl<T: Clone> Future for RecvOwned<T> { type Output = (T, Receiver<T>); } and avoid the whole business of self-referential futures

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
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
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Feature request: Allow non-Send broadcast values in more (generic) contexts
2 participants
@jplatte @Darksonn