sync: watch::Sender::opened method/future #7240
Labels
A-tokio
Area: The main tokio crate
C-feature-request
Category: A feature request.
M-sync
Module: tokio/sync
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 byselect!
ing onclosed
.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
Sender::opened
which is essentially just a mirror ofclosed
.Receiver::drop
intoReceiver::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.refcount
fromfrom_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 onclosed
when you "open" and vice-versa).receiver_count
checks make this scenario unlikely to occur.Do nothing and just continue implementing manually over what's already there.
fetch_add
atomic, so the DIY solution cannot conditionallynotify_waiter
, and instead must always notify after callingsubscribe
.Additional context
I'd be happy to send a PR if there's interest.
The text was updated successfully, but these errors were encountered: