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: watch::Sender::opened method/future #7240

Open
Daniel-Aaron-Bloom opened this issue Apr 4, 2025 · 0 comments
Open

sync: watch::Sender::opened method/future #7240

Daniel-Aaron-Bloom opened this issue Apr 4, 2025 · 0 comments
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-sync Module: tokio/sync

Comments

@Daniel-Aaron-Bloom
Copy link

Daniel-Aaron-Bloom commented Apr 4, 2025

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

I have a background thread doing expensive HTTP polling to fetch the latest status for other consumer threads to use. watch is great for this because consumers only need a reasonably recent value and the background thread can stop making HTTP requests when there are no listeners by select!ing on closed.

All this works great, but it's frustrating to have to use an entirely different signalling method to resume HTTP polling again when new consumer threads subscribe.

Describe the solution you'd like

  • Add a method Sender::opened which is essentially just a mirror of closed.
  • Mirror the signalling from Receiver::drop into Receiver::from_shared.

Describe alternatives you've considered

  • Put the signalling into Sender::subscribe since that's the only code-path which can ever actually invoke the signalling.

    • The runtime penalty of a single if statement seems small.
    • The complexity of returning refcount from from_shared is bad.
    • subscribe is the only possible code-path right now, but that might not always be the case, so putting it here is increasing future bug risk.
  • Use a secondary signal instead of shared.notify_tx to reduce cross talk (i.e. waking threads waiting on closed when you "open" and vice-versa).

    • receiver_count checks make this scenario unlikely to occur.
    • The penalty of a single incorrect wake every now and then is already baked in if someone decides to subscribe and immediately drop.
    • Making everyone pay for another notifier they're never going to use is bad.
  • Do nothing and just continue implementing manually over what's already there.

    • 😢
    • Callers lack access to the result of the fetch_add atomic, so the DIY solution cannot conditionally notify_waiter, and instead must always notify after calling subscribe.

Additional context

I'd be happy to send a PR if there's interest.

@Daniel-Aaron-Bloom Daniel-Aaron-Bloom added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Apr 4, 2025
@mox692 mox692 added the M-sync Module: tokio/sync label Apr 5, 2025
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