After creating the SslStream it first has to be connected before it can
actually be used to initiate the WebSocket connection.
While this technically is a breaking API changes because of wrapping the
stream in a Pin<Box<_>> and having this as part of the public API, the
old API simply didn't work so if anybody's code fails to compile now
they would've had non-functioning code anyway.
This doesn't make sense. For Unpin types, Pin does nothing, so Pin::new() is sufficient.
However Pin::new is only implemented for `Pin<P> where <P as Deref>::Target: Unpin`, so if it weren't Unpin,
you would have to use unsafe { Pin::new_unchecked(s) }, `Pin::new()` wouldn't compile.
Thus project and Pin::new together is always a code smell.
warning: use of `ok_or` followed by a function call
--> src/lib.rs:379:10
|
379 | .ok_or(tungstenite::Error::Url("Url scheme not supported".into()))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try this: `ok_or_else(|| tungstenite::Error::Url("Url scheme not supported".into()))`
Partially based on tungstenite commits
- 46dfd9ed3ee75b0261e9f5f71c8e70492407248b by Alexey Galakhov
- 31010fd636b3edc683199e3182ea34d799118d5b by Alexey Galakhov
Instead simply send an owned Closed message. This simplifies the code
and among other things also handles errors like WouldBlock correctly
instead of handling them like a real error.
The same functionality is already provided via StreamExt::send() and
unlike the custom implementation it handles WouldBlock correctly and not
as an error.
As a side effect also gets rid of unsafe code and raw pointers.
We have the problem that external read operations (i.e. the Stream impl)
can trigger both read (AsyncRead) and write (AsyncWrite) operations on
the underyling stream. At the same time write operations (i.e. the Sink
impl) can trigger write operations (AsyncWrite) too.
Both the Stream and the Sink can be used on two different tasks, but it
is required that AsyncRead and AsyncWrite are only ever used by a single
task (or better: with a single waker) at a time.
Doing otherwise would cause only the latest waker to be remembered, so
in our case either the Stream or the Sink impl would potentially wait
forever to be woken up because only the other one would've been woken
up.
To solve this we implement a waker proxy that has two slots (one for
read, one for write) to store wakers. One waker proxy is always passed
to the AsyncRead, the other to AsyncWrite so that they will only ever
have to store a single waker, but internally we dispatch any wakeups to
up to two actual wakers (one from the Sink impl and one from the Stream
impl).
QiuJiangkun