Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upAsync/await support #242
Async/await support #242
Comments
This comment has been minimized.
This comment has been minimized.
|
I'm not sure. Obviously, it should eventually support Is it proper for Unless some other contributor steps in, it's unlikely that rust-websocket would support tokio 0.2 this year. |
This comment has been minimized.
This comment has been minimized.
|
@vi I can see what I can do by myself. Would you want to remove the synchronous library? I'd also update hyper, as it seems the sensible thing to do. |
This comment has been minimized.
This comment has been minimized.
|
This all may result in a new websocket library with only partial resemblance of If it works well, it may be a good idea to grant the crate name |
This comment has been minimized.
This comment has been minimized.
|
Taking that as a yes. I wouldn't jump immediately to a 1.0, but it'll obviously be a breaking change. |
This comment has been minimized.
This comment has been minimized.
Not sure. Maybe synchronous version can just use current thread executor under the hood, but still support user-facing API as if it is a pre-async world. There may be multiple |
This comment has been minimized.
This comment has been minimized.
|
Ok, that could certainly work. I'm going to attempt a conversion to async, initially scrapping the synchronous API. If that works, it shouldn't be too difficult to rebuild the sync functions, just using |
This comment has been minimized.
This comment has been minimized.
|
You may want to use (currently unpublished) websocket-lowlevel crate for Hyper-free part of rust-websocket. |
This comment has been minimized.
This comment has been minimized.
|
Is there any update on this, anybody working on this? I could probably spend some time on updating current git master to std futures and tokio 0.2 if there's interest in it, but I won't have time for doing any other refactoring and reorganization of the crate based on the WIP (?) |
This comment has been minimized.
This comment has been minimized.
|
It seems the |
This comment has been minimized.
This comment has been minimized.
|
Recent comments suggest to rename things and maybe further split away But anyway if I personally continue something about |
This comment has been minimized.
This comment has been minimized.
|
Ok, no worries :) Then I'll start work based on the branch and send you a PR for that once it's working. Would you want to publish it on crates.io as is then or would you block on splitting it further? From what I understand the goal would be to split into a) a base crate, b) futures support (but not tokio-specific?), c) something to glue things together with hyper? Also do you want to continue maintaining this project at all or would you be looking for someone to take it over or a co-maintainer? |
This comment has been minimized.
This comment has been minimized.
|
Even if async+edition2018+split version is already ready, I'm going to publish an intermediate version which is already split, but still supports old Rust, old edition and old futures-0.1. Only the And if to drop old Rust compat then API may be changed drastically as well to be more suitable for |
This comment has been minimized.
This comment has been minimized.
|
Ok, so I'll start with the port to new futures/tokio based on the split branch and then we'll see where we end up :) |
This comment has been minimized.
This comment has been minimized.
|
I have an initial version here https://github.com/sdroege/rust-websocket/tree/tokio-0.2 Covers the lowlevel crate and the tests are passing. I'm cleaning up the tests now and update the docs, then to the highlevel crate. |
This comment has been minimized.
This comment has been minimized.
|
And also updated the docs/tests to async/await now. Looks much nicer now if you ask me. |
This comment has been minimized.
This comment has been minimized.
|
So when going through the highlevel crate, I was wondering if all of that should be kept. Based on the lowlevel crate and hyper it seems like the functionality of the highlevel crate can be implemented in a few dozen lines of code. I'm not going to port the highlevel crate to new tokio at this point because of time constraints, and we should probably first of all decide how the whole API should look like at that point before porting. |
This comment has been minimized.
This comment has been minimized.
|
A simple example without proper error handling for that can be found here: https://gist.github.com/sdroege/b1a6cc33ff9a81ae3b52125aeb9aa9c5 |
This comment has been minimized.
This comment has been minimized.
|
@sdroege Are you interested in being a maintainer of |
This comment has been minimized.
This comment has been minimized.
I already have a lot of other crates and libraries in other languages to maintain :) I can definitely help out a bit, but I think to move forward here we first of all need to decide on a general direction for this crate. Personally I would
|
This comment has been minimized.
This comment has been minimized.
|
For websocat I'm going to use my https://github.com/vi/http-bytes as a "minimal custom HTTP implementation". |
This comment has been minimized.
This comment has been minimized.
Can't it be executor-independent library without explicit mentions of Tokio or other framework? |
This comment has been minimized.
This comment has been minimized.
The problem is that tokio has its own By having optional tokio support you could include a
Perfect, so maybe we could simply have a |
This comment has been minimized.
This comment has been minimized.
|
Is there a multi-runtime analogue of (I'm not very aware of post- |
This comment has been minimized.
This comment has been minimized.
Unfortunately not yet. OTOH it's quite easy to implement on top of IMHO the main problem right now is that tokio has its own
They have different reactors and require their specific reactor to work. Having both is unfortunate but I hope this will solve itself over time... I think we can make FWIW: I have a full hyper client implementation now with error handling and everything, that could become the base of the |
This comment has been minimized.
This comment has been minimized.
|
I've added the hyper thing as a sub-crate in https://github.com/sdroege/rust-websocket/tree/tokio-0.2 in any case. |
This comment has been minimized.
This comment has been minimized.
|
I beg your pardon for my ignorance, but I wonder what are the key differences between this project and |
This comment has been minimized.
This comment has been minimized.
|
@frol, I haven't tried Existence of @sdroege, Have you tried |
This comment has been minimized.
This comment has been minimized.
|
Last time I checked tungestenite (or maybe I'm confused?) it required running a separate thread and couldn't be directly integrated with a futures executor. Maybe that changed though. tokio-tungestenite is currently using old tokio 0.1 and has no async/await support, that's why I didn't look into it again recently. I didn't see that there was a PR (or maybe it wasn't there back then yet). |
This comment has been minimized.
This comment has been minimized.
I checked the tokio-tungstenite PR now and that works very well and does not involve adding a new thread. The API is also very similar to what we have here, so maybe this can be deprecated in favor of tokio-tungstenite indeed. |
This comment has been minimized.
This comment has been minimized.
|
Added a note about |
This comment has been minimized.
This comment has been minimized.
|
Note: merged This is an intermediate version with not all pending PR merged, mostly for gradual upgrading. Further splits, edition2018, dropping very old rustc support, futures 0.3, etc. are for |
This comment has been minimized.
This comment has been minimized.
|
Guys I have a question regarding mentioned crates architecture.
But Rust borrow checker, should prevent to read and write on same mutable object in different threads at the same time. Is it mean that tungstenite is only half-duplex? rust-websocket split channel in two parts - receiver and sender and this is seems to me better design . tokio discuss this problem to ( Split I/O resources paragraph ) |
This comment has been minimized.
This comment has been minimized.
|
@cheblin I am not familiar with the released/stable tungstenite, but tokio-tungstenite with tokio 0.2 support has the split method, and it works. |
This comment has been minimized.
This comment has been minimized.
|
That works by placing everything into an (async) mutex IIRC, so that only one thread at a time can access the socket. In theory for a plain TCP connection (not TLS) it would be thread-safe to write and read separately on different threads at the same time but not in general. There's also async-tungstenite now btw (which I'm currently maintaining), which is a fork of tokio-tungstenite that is not bound to any specific runtime but has optional support for async-std. |
Do you have a roadmap as to the async/await-based API? I think it will require migrating to 2018 edition and other breaking changes, so I wonder what the plan is.