Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WakerProxy may be unnecessary #163

Open
quininer opened this issue Apr 16, 2021 · 3 comments
Open

WakerProxy may be unnecessary #163

quininer opened this issue Apr 16, 2021 · 3 comments

Comments

@quininer
Copy link

I found it from deno's discussion.

tokio-tungstenite uses the trick of WakerProxy to solve the wake-up problem of two-way IO. but this is not necessary in tokio, the related problem is reported as tokio-rs/tls#40 .

In short, the latest versions of tokio::net::TcpStream and tokio-rustls are not affected by this issue.

Given that this trick may cause lot spurious wakeups, we may be possible to provide an opt-out feature gate?

@strohel
Copy link
Contributor

strohel commented Apr 19, 2021

Thanks for a heads-up, @quininer. I'm not expert on that part of the code, but it indeed looks like we can now simplify thanks to upstream bugfixes. CC @application-developer-DA @jxs @agalakhov.

@jxs
Copy link
Contributor

jxs commented Apr 20, 2021

hi @quininer, tokio-tungstenite needs a compat layer similar to the one used on tokio-native-tls as tungstenite uses Read and Write traits directly. It started to use the same trick of tokio-native-tls but was since upgraded to use the WakerProxy trick on 6e566ec

I see two possibilities:
1 - revert to use the same technique as tokio-native-tls, is this what you are suggesting too right @quininer ? (has the unsafe disadvantage but is simple to implement)
2 - decouple base tungstenite from IO (similar to how quiche was conceived, also see the SansIO manifesto) and have IO implementations depend on it (considerable time needed to try to implement, not 100% sure if feasible)

I would suggest going for 1 now, and consider 2 in the mid term
cc @sdroege

@quininer
Copy link
Author

This sounds great, and I am looking forward to 2. It would be great if there is a websocket library that works under no_std.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants