Introduce an alternative day-4-afternoon: async #492
Conversation
|
Note that this depends on #487. Once that lands, I'll rebase and the diff will contain only the async bits. |
|
rebase'd @rbehjati do you want to write some of these chapters? I think you can push to this PR, or I could rebase this PR to point to an upstream branch and we could make a few PRs against that branch. |
src/async.md
Outdated
| executing each task until it would block, then switching to another task that is | ||
| ready to make progress. The model scales to higher concurrency than threads | ||
| because the per-task overhead is typically very low and operating systems | ||
| provide means of efficiently selecting tasks that can make progress. |
There was a problem hiding this comment.
nit: It sounds like there is inherent OS support for async/await. Perhaps reword to something like "the async/await implementation relies on OS primitive to efficiently select the next tasks to run".
There was a problem hiding this comment.
I think I addressed this, but I'm happy for more editing :)
| At a high level, async Rust code looks very much like "normal" sequential code: | ||
|
|
||
| ```rust,editable | ||
| use tokio::time; |
There was a problem hiding this comment.
Is it possible to skip using tokio in this first example, and use futures and block_on?
There was a problem hiding this comment.
futures does not provide any time-based waking functionality. The only functionality in futures that would be non-trivial would be to send data over a channel, but I want to keep this example simple and parallel to the threads example.
Using futures for one of the later examples is a good idea, though.
Sure. I can help. Most likely will have time to work on it in late March. |
|
Also, I think it should be possible to add the content gradually (in separate PRs) and only add a link to it in |
I think this won't work, or at least would be confusing; this PR itself is getting errors because SUMMARY is incorrect. Instead, I'll push to an |
Fixes #181.