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

[Daniel-Aaron-Bloom]

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.