public-collect/books-futures-explained
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

formatting

Browse Source
This commit is contained in:
Carl Fredrik Samson
2020-04-01 23:15:36 +02:00
parent 7f7fe098f3
commit 8900666a55
5 changed files with 51 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
book/1_why_futures.html
View File

@@ -157,14 +157,14 @@ pros and cons for each of them.</p>
<p>Now one way of accomplishing this is letting the OS take care of everything for <p>Now one way of accomplishing this is letting the OS take care of everything for
us. We do this by simply spawning a new OS thread for each task we want to us. We do this by simply spawning a new OS thread for each task we want to
accomplish and write code like we normally would.</p> accomplish and write code like we normally would.</p>
<p><strong>Pros:</strong></p> <p><strong>Advantages:</strong></p>
<ul> <ul>
<li>Simple</li> <li>Simple</li>
<li>Easy to use</li> <li>Easy to use</li>
<li>Switching between tasks is reasonably fast</li> <li>Switching between tasks is reasonably fast</li>
<li>You get parallelism for free</li> <li>You get parallelism for free</li>
</ul> </ul>
<p><strong>Cons:</strong></p> <p><strong>Drawbacks:</strong></p>
<ul> <ul>
<li>OS level threads come with a rather large stack. If you have many tasks <li>OS level threads come with a rather large stack. If you have many tasks
waiting simultaneously (like you would in a web-server under heavy load) you'll waiting simultaneously (like you would in a web-server under heavy load) you'll
@@ -218,7 +218,7 @@ task is finished</li>
</ol> </ol>
<p>These &quot;jumps&quot; are know as context switches. Your OS is doing it many times each <p>These &quot;jumps&quot; are know as context switches. Your OS is doing it many times each
second as you read this.</p> second as you read this.</p>
<p>The main advantages are:</p> <p><strong>Advantages:</strong></p>
<ol> <ol>
<li>Simple to use. The code will look like it does when using OS threads.</li> <li>Simple to use. The code will look like it does when using OS threads.</li>
<li>A &quot;context switch&quot; is reasonably fast</li> <li>A &quot;context switch&quot; is reasonably fast</li>
@@ -227,22 +227,23 @@ thousands of green threads running.</li>
<li>It's easy to incorporate <a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/green-threads#preemptive-multitasking"><em>preemtion</em></a> <li>It's easy to incorporate <a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/green-threads#preemptive-multitasking"><em>preemtion</em></a>
which puts a lot of control in the hands of the runtime implementors.</li> which puts a lot of control in the hands of the runtime implementors.</li>
</ol> </ol>
<p>The main cons are:</p> <p><strong>Drawbacks:</strong></p>
<ol> <ol>
<li>The stacks might need to grow. Solving this is not easy and will have a cost.</li> <li>The stacks might need to grow. Solving this is not easy and will have a cost.</li>
<li>You need to save all the CPU state on every switch</li> <li>You need to save all the CPU state on every switch</li>
<li>It's not a <em>zero cost abstraction</em> (which is one of the reasons Rust removed <li>It's not a <em>zero cost abstraction</em> (Rust had green threads early on and this
them early on).</li> was one of the reasons they were removed).</li>
<li>Complicated to implement correctly if you want to support many different <li>Complicated to implement correctly if you want to support many different
platforms.</li> platforms.</li>
</ol> </ol>
<p>If you were to implement green threads in Rust, it could look something like <p>If you were to implement green threads in Rust, it could look something like
this:</p> this:</p>
<pre><code>The example presented below is from an earlier book I wrote about green <blockquote>
threads called [Green Threads Explained in 200 lines of Rust.](https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/) <p>The example presented below is from an earlier book I wrote about green
If you want to know what's going on everything is explained in detail threads called <a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/">Green Threads Explained in 200 lines of Rust.</a>
in that book. If you want to know what's going on you'll find everything explained in detail
</code></pre> in that book.</p>
</blockquote>
<pre><pre class="playpen"><code class="language-rust">#![feature(asm)] <pre><pre class="playpen"><code class="language-rust">#![feature(asm)]
#![feature(naked_functions)] #![feature(naked_functions)]
use std::ptr; use std::ptr;
@@ -528,6 +529,10 @@ impl Runtime {
} }
} }
</code></pre></pre> </code></pre></pre>
<p>We're keeping this super simple, and you might wonder what's the difference
between this approach and the one using OS threads. The difference is that the
callbacks are run on the same thread. The OS threads we create are basically
just used as timers.</p>
</main> </main>

27
book/print.html
View File

@@ -199,14 +199,14 @@ pros and cons for each of them.</p>
<p>Now one way of accomplishing this is letting the OS take care of everything for <p>Now one way of accomplishing this is letting the OS take care of everything for
us. We do this by simply spawning a new OS thread for each task we want to us. We do this by simply spawning a new OS thread for each task we want to
accomplish and write code like we normally would.</p> accomplish and write code like we normally would.</p>
<p><strong>Pros:</strong></p> <p><strong>Advantages:</strong></p>
<ul> <ul>
<li>Simple</li> <li>Simple</li>
<li>Easy to use</li> <li>Easy to use</li>
<li>Switching between tasks is reasonably fast</li> <li>Switching between tasks is reasonably fast</li>
<li>You get parallelism for free</li> <li>You get parallelism for free</li>
</ul> </ul>
<p><strong>Cons:</strong></p> <p><strong>Drawbacks:</strong></p>
<ul> <ul>
<li>OS level threads come with a rather large stack. If you have many tasks <li>OS level threads come with a rather large stack. If you have many tasks
waiting simultaneously (like you would in a web-server under heavy load) you'll waiting simultaneously (like you would in a web-server under heavy load) you'll
@@ -260,7 +260,7 @@ task is finished</li>
</ol> </ol>
<p>These &quot;jumps&quot; are know as context switches. Your OS is doing it many times each <p>These &quot;jumps&quot; are know as context switches. Your OS is doing it many times each
second as you read this.</p> second as you read this.</p>
<p>The main advantages are:</p> <p><strong>Advantages:</strong></p>
<ol> <ol>
<li>Simple to use. The code will look like it does when using OS threads.</li> <li>Simple to use. The code will look like it does when using OS threads.</li>
<li>A &quot;context switch&quot; is reasonably fast</li> <li>A &quot;context switch&quot; is reasonably fast</li>
@@ -269,22 +269,23 @@ thousands of green threads running.</li>
<li>It's easy to incorporate <a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/green-threads#preemptive-multitasking"><em>preemtion</em></a> <li>It's easy to incorporate <a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/green-threads#preemptive-multitasking"><em>preemtion</em></a>
which puts a lot of control in the hands of the runtime implementors.</li> which puts a lot of control in the hands of the runtime implementors.</li>
</ol> </ol>
<p>The main cons are:</p> <p><strong>Drawbacks:</strong></p>
<ol> <ol>
<li>The stacks might need to grow. Solving this is not easy and will have a cost.</li> <li>The stacks might need to grow. Solving this is not easy and will have a cost.</li>
<li>You need to save all the CPU state on every switch</li> <li>You need to save all the CPU state on every switch</li>
<li>It's not a <em>zero cost abstraction</em> (which is one of the reasons Rust removed <li>It's not a <em>zero cost abstraction</em> (Rust had green threads early on and this
them early on).</li> was one of the reasons they were removed).</li>
<li>Complicated to implement correctly if you want to support many different <li>Complicated to implement correctly if you want to support many different
platforms.</li> platforms.</li>
</ol> </ol>
<p>If you were to implement green threads in Rust, it could look something like <p>If you were to implement green threads in Rust, it could look something like
this:</p> this:</p>
<pre><code>The example presented below is from an earlier book I wrote about green <blockquote>
threads called [Green Threads Explained in 200 lines of Rust.](https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/) <p>The example presented below is from an earlier book I wrote about green
If you want to know what's going on everything is explained in detail threads called <a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/">Green Threads Explained in 200 lines of Rust.</a>
in that book. If you want to know what's going on you'll find everything explained in detail
</code></pre> in that book.</p>
</blockquote>
<pre><pre class="playpen"><code class="language-rust">#![feature(asm)] <pre><pre class="playpen"><code class="language-rust">#![feature(asm)]
#![feature(naked_functions)] #![feature(naked_functions)]
use std::ptr; use std::ptr;
@@ -570,6 +571,10 @@ impl Runtime {
} }
} }
</code></pre></pre> </code></pre></pre>
<p>We're keeping this super simple, and you might wonder what's the difference
between this approach and the one using OS threads. The difference is that the
callbacks are run on the same thread. The OS threads we create are basically
just used as timers.</p>
<h1><a class="header" href="#some-background-information" id="some-background-information">Some background information</a></h1> <h1><a class="header" href="#some-background-information" id="some-background-information">Some background information</a></h1>
<blockquote> <blockquote>
<p><strong>Relevant for:</strong></p> <p><strong>Relevant for:</strong></p>

2
book/searchindex.js
View File

File diff suppressed because one or more lines are too long

2
book/searchindex.json
View File

File diff suppressed because one or more lines are too long

29
src/1_why_futures.md
View File

@@ -10,14 +10,14 @@ Now one way of accomplishing this is letting the OS take care of everything for
us. We do this by simply spawning a new OS thread for each task we want to us. We do this by simply spawning a new OS thread for each task we want to
accomplish and write code like we normally would. accomplish and write code like we normally would.
**Pros:** **Advantages:**
- Simple - Simple
- Easy to use - Easy to use
- Switching between tasks is reasonably fast - Switching between tasks is reasonably fast
- You get parallelism for free - You get parallelism for free
**Cons:** **Drawbacks:**
- OS level threads come with a rather large stack. If you have many tasks - OS level threads come with a rather large stack. If you have many tasks
waiting simultaneously (like you would in a web-server under heavy load) you'll waiting simultaneously (like you would in a web-server under heavy load) you'll
@@ -79,7 +79,7 @@ These "jumps" are know as context switches. Your OS is doing it many times each
second as you read this. second as you read this.
The main advantages are: **Advantages:**
1. Simple to use. The code will look like it does when using OS threads. 1. Simple to use. The code will look like it does when using OS threads.
2. A "context switch" is reasonably fast 2. A "context switch" is reasonably fast
@@ -88,22 +88,22 @@ thousands of green threads running.
4. It's easy to incorporate [_preemtion_](https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/green-threads#preemptive-multitasking) 4. It's easy to incorporate [_preemtion_](https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/green-threads#preemptive-multitasking)
which puts a lot of control in the hands of the runtime implementors. which puts a lot of control in the hands of the runtime implementors.
The main cons are: **Drawbacks:**
1. The stacks might need to grow. Solving this is not easy and will have a cost. 1. The stacks might need to grow. Solving this is not easy and will have a cost.
2. You need to save all the CPU state on every switch 2. You need to save all the CPU state on every switch
3. It's not a _zero cost abstraction_ (which is one of the reasons Rust removed 3. It's not a _zero cost abstraction_ (Rust had green threads early on and this
them early on). was one of the reasons they were removed).
4. Complicated to implement correctly if you want to support many different 1. Complicated to implement correctly if you want to support many different
platforms. platforms.
If you were to implement green threads in Rust, it could look something like If you were to implement green threads in Rust, it could look something like
this: this:
The example presented below is from an earlier book I wrote about green >The example presented below is from an earlier book I wrote about green
threads called [Green Threads Explained in 200 lines of Rust.](https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/) >threads called [Green Threads Explained in 200 lines of Rust.](https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/)
If you want to know what's going on everything is explained in detail >If you want to know what's going on you'll find everything explained in detail
in that book. >in that book.
```rust ```rust
#![feature(asm)] #![feature(asm)]
@@ -397,4 +397,9 @@ impl Runtime {
} }
} }
} }
``` ```
We're keeping this super simple, and you might wonder what's the difference
between this approach and the one using OS threads. The difference is that the
callbacks are run on the same thread. The OS threads we create are basically
just used as timers.