provide a non-destructive mechanism to determine if a sink/stream are paired #2797
Conversation
There was a problem hiding this comment.
Thanks, this seems reasonable. Channels also have similar APIs.
futures-util/src/lock/bilock.rs
Outdated
| @@ -69,6 +69,11 @@ impl<T> BiLock<T> { | |||
| (Self { arc: arc.clone() }, Self { arc }) | |||
| } | |||
|
|
|||
| /// Returns `true` only if the two `BiLock<T>`s originated from the same call to `BiLock::new`. | |||
| pub fn are_paired(first: &Self, second: &Self) -> bool { | |||
There was a problem hiding this comment.
Why is this different than others? (are_paired(_, _) vs is_pair(&self, _)).
There was a problem hiding this comment.
There's no technical reason. I went with the non-method implementation for BiLock because I felt like the instances are more independent than the sink/stream pair, but the primary purpose of the abstraction is to only be coupled to one other instance so the method syntax is still reasonable. The other benefit of using the method signature is that it's more consistent with the sink/stream api, which would be more consistent with reunite.
I've made that change and rebased to hopefully get a clean CI run. Thanks for taking a look.
There was a problem hiding this comment.
Thanks.
I noticed a similar function in tokio called is_pair_of. It would make sense to give it the same name to make it easier for users to find.
Also, we have split in io module too. Could you add the same methods to it?
| } | ||
|
|
||
| #[test] | ||
| #[cfg_attr(docsrs, doc(cfg(feature = "sink")))] |
There was a problem hiding this comment.
| #[cfg_attr(docsrs, doc(cfg(feature = "sink")))] |
Test code will not be displayed in docs.
| use crate::{sink::Sink, stream::StreamExt}; | ||
| use core::marker::PhantomData; | ||
|
|
||
| struct NopStream<Item> { |
There was a problem hiding this comment.
This struct is a hack because I couldn't find a type to use without introducing a dependency. I'm open to suggestions if there's something available that I'm missing.
taiki-e
added
the
0.3-backport: pending
taiki-e
added
0.3-backport: completed
and removed
0.3-backport: pending
|
Published in 0.3.30. |
The only mechanism I could find to determine if a sink and stream are paired is
reunitewhich takes ownership of the values. The mechanism proposed here allows the caller to determine if the values are paired without mutation.This behavior is useful in the case where a service receives messages from multiple connections and would like to send messages to the non-originating sinks. Currently there appears to be no way for the server to determine which sink is paired with the connection that originated the message.
I'm not tied to the function names and welcome any suggestions.