Closed keksbg closed 2 years ago
I'm not sure there is any valid use case for it. How would you use it?
If you're using Tokio, you usually don't use the mio
simultaneously since mio
is something that Tokio relies upon internally. You won't be able to trivially implement the Source
like that for the whole stream since the underlying stream is unlikely to implement Source
(tokio::TcpStream
does not).
While you could potentially pass a stream that implements Source
, such a stream won't be useful within Tokio runtime. If you're willing to use mio::Source
, you're likely to be implementing your own runtime in which case you might want to work with tungstenite
directly instead of tokio-tungstenite
. But chances are, you don't really want to do this and rely on Tokio instead 😉 (in which case the implementation of Source
becomes irrelevant).
I see, thank you for the explanation.
Quick and dirty commit to implement the
Source
trait frommio
to be able to poll on theWebSocketStream
struct as a separate feature undermio
. Did it because I was going to use it in my own code that usesmio
to poll but I wasn't able to find an easy way to wrapWebSocketStream
.If there's an easy way to do this in user code please do let me know (even though I don't think it's a bad idea to implement it at the dependency level, considering it's also called tokio-tungstenite), as the compiler does not like me implementing traits, which are defined outside of my crate, for types that are defined outside of my crate. Either one has to be defined in the same crate, per E0117.