-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Pre-RFC Tokio/Futures Cookbook #86
Comments
The issue I struggled with for a few weeks was having an open bidirectional WebSocket connection, but at the same time allowing the user to enqueue messages to be sent. So the sink of the WebSocket must be available for both user messages and signaling messages. I finally solved the issue by using two streams and one sink, and async channels: https://github.com/saltyrtc/saltyrtc-client-rs/blob/0c44e669941b62a6cb8a2fed4dbc2399f40703b6/src/lib.rs#L581-L726 Maybe something like that (simplified) could be included. I struggled with the fact that most examples only do request-response, which is easy. (My code is still quite ugly with many ignored errors, should get cleaned up over the next few days.) |
Thanks, @dbrgn - so maybe your example could be described as "converging multiple event sources (streams or otherwise) into a sink" ? |
Yes, I think that would work! Maybe another one could be "communicating between futures using channels". |
Another common example in the "multiple event sources" category (this is something I've struggled with multiple times) is: a single event loop that can wait on a TCP socket, a UDP socket, and a timer |
One thing that would be useful would be listening to STDIN and writing to STDOUT/STDERR in a cross-portable way. I spent hours trying to figure out how things work in Windows, only to discover that they don't really. |
@eminence - Yea, that should be one of the core "design patterns". That should be right in the wheelhouse of a good futures/streams library. @timClicks - Hmm. I definitely agree. Really Stdout isn't async on Linux either, because stdout buffers no matter what, and it might block. This should be documented.. If we make a Recipe for it, it would be something like "stdout as a Sink" and "stdin as a source" which would have an explanation and some example code for how to use a thread and blocking code to achive your goal. |
I was just pointed to rust-lang-nursery/rust-cookbook#267 |
Sorry for the delay, we should definitely put together a cookbook. Docs should become a focus very soon as the final bits of the release come together. |
Might I request a tutorial on the best way to run something like a chat server? Could just be line based telnet, doesn't have to be a full IRC stack or anything. A lot of the proposed examples look like a "connect, response, close" style. Something where connections have to be maintained and the server tracks some state over time would be a good way to show a "serious" use case for the lib. |
@Lokathor tutorial: https://tokio.rs/docs/getting-started/chat/ example: https://github.com/tokio-rs/tokio/blob/master/examples/chat.rs |
A good example would be to write a stream combinator that takes up to M messages or process for up to N seconds. |
I think it's also important to have a few throughout |
For anyone still interested in this, I would like to up prioritize getting a cookbook setup. Discussion is moved here, please help out 👍 I will close this issue now. |
Intent
The deliverable of this ticket will be a fairly complete list of topics for v1 of a Tokio and Futures cookbook, as well as a document structure and design guideline for ongoing additions. The finished product is intended to address the cookbook part of #13.
In addition to fielding and refining topics, there is a question of the actual structure of the topics as well. This is because many of the topics have valid solutions as compositions of combinators, or as implementations as futures traits (or both).
Also, at the high level, I'd like to come up with heuristics for the size and scope of what is considered a 'recipe' as many of these might exceed those, and could be broken down into sub-recipes.
Format
The plan is to plagiarize the structure and format of the existing Rust Cookbook
Hosting
This effort does not propose an actual hosting location. It is hoped that it will live either as a subcategory of the existing tokio documentation site, or under a
Futures
topic of the Rust Cookbook.Topics
Common Tasks
Managing Monomorphization (need a better name)
Io Tasks
Standard Protocols
Advanced networking
The text was updated successfully, but these errors were encountered: