shared::OneshotReceiver and cancellation

[goffrie]

Hi! Big fan of this library :) I wanted to note a gotcha I ran into today: dropping a OneshotReceiver causes the channel to be closed, even if there is an active ChannelReceiveFuture reading from it. This is a bit annoying since often I'm passing the receiver to something that just wants a future, but then I have to bundle the OneshotReceiver together with it. So for now I've switched to futures::channel::oneshot for oneshots.

In general, I'm not sure why the OneshotReceiver can't implement Future directly and avoid the entire .receive() dance. At least, this behaviour is something that should be documented :)

[Matthias247]

Interesting gotcha! Haven't thought about it myself, since I didn't use the Oneshots so far.

In general, I'm not sure why the OneshotReceiver can't implement Future directly

This could work, but requires the Receiver to store the the future internally - essentially what is now the ChannelReceiveFuture would become the Receiver. The downside is that this would make it !Unpin. Depending on the use-case it might make it more painful to work with.

Another option is that calling receive consumes the Receiver without closing the channel.
I'm not opposed on changing the behavior to any of those. However it's a breaking change

[goffrie]

The downside is that this would make it !Unpin.

True. I don't see this as a huge downside, since anyone holding (but not polling) a Receiver can wrap it with a struct that is Unpin, but it is a bit annoying.

Another option is that calling receive consumes the Receiver without closing the channel.

This would be good as well. This makes sense to me too since I'm not sure what it means for multiple receive futures to exist on the same channel.