914 lines
39 KiB
HTML
914 lines
39 KiB
HTML
<!DOCTYPE HTML>
|
|
<html lang="en" class="sidebar-visible no-js">
|
|
<head>
|
|
<!-- Book generated using mdBook -->
|
|
<meta charset="UTF-8">
|
|
<title>Futures Explained in 200 Lines of Rust</title>
|
|
|
|
<meta name="robots" content="noindex" />
|
|
|
|
|
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
|
<meta name="description" content="">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<meta name="theme-color" content="#ffffff" />
|
|
|
|
<link rel="shortcut icon" href="favicon.png">
|
|
<link rel="stylesheet" href="css/variables.css">
|
|
<link rel="stylesheet" href="css/general.css">
|
|
<link rel="stylesheet" href="css/chrome.css">
|
|
<link rel="stylesheet" href="css/print.css" media="print">
|
|
|
|
<!-- Fonts -->
|
|
<link rel="stylesheet" href="FontAwesome/css/font-awesome.css">
|
|
<link href="https://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800" rel="stylesheet" type="text/css">
|
|
<link href="https://fonts.googleapis.com/css?family=Source+Code+Pro:500" rel="stylesheet" type="text/css">
|
|
|
|
<!-- Highlight.js Stylesheets -->
|
|
<link rel="stylesheet" href="highlight.css">
|
|
<link rel="stylesheet" href="tomorrow-night.css">
|
|
<link rel="stylesheet" href="ayu-highlight.css">
|
|
|
|
<!-- Custom theme stylesheets -->
|
|
|
|
|
|
|
|
</head>
|
|
<body class="light">
|
|
<!-- Provide site root to javascript -->
|
|
<script type="text/javascript">
|
|
var path_to_root = "";
|
|
var default_theme = "light";
|
|
</script>
|
|
|
|
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
|
<script type="text/javascript">
|
|
try {
|
|
var theme = localStorage.getItem('mdbook-theme');
|
|
var sidebar = localStorage.getItem('mdbook-sidebar');
|
|
|
|
if (theme.startsWith('"') && theme.endsWith('"')) {
|
|
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
|
}
|
|
|
|
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
|
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
|
}
|
|
} catch (e) { }
|
|
</script>
|
|
|
|
<!-- Set the theme before any content is loaded, prevents flash -->
|
|
<script type="text/javascript">
|
|
var theme;
|
|
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
|
if (theme === null || theme === undefined) { theme = default_theme; }
|
|
document.body.className = theme;
|
|
document.querySelector('html').className = theme + ' js';
|
|
</script>
|
|
|
|
<!-- Hide / unhide sidebar before it is displayed -->
|
|
<script type="text/javascript">
|
|
var html = document.querySelector('html');
|
|
var sidebar = 'hidden';
|
|
if (document.body.clientWidth >= 1080) {
|
|
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
|
sidebar = sidebar || 'visible';
|
|
}
|
|
html.classList.remove('sidebar-visible');
|
|
html.classList.add("sidebar-" + sidebar);
|
|
</script>
|
|
|
|
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
|
<div class="sidebar-scrollbox">
|
|
<ol class="chapter"><li><a href="0_0_introduction.html"><strong aria-hidden="true">1.</strong> Introduction</a></li><li><a href="0_1_background_information.html"><strong aria-hidden="true">2.</strong> Some background information</a></li><li><ol class="section"><li><a href="0_1_1_trait_objects.html"><strong aria-hidden="true">2.1.</strong> Trait objects and fat pointers</a></li><li><a href="0_1_2_generators_pin.html"><strong aria-hidden="true">2.2.</strong> Generators and Pin</a></li></ol></li><li><a href="0_2_naive_implementation.html"><strong aria-hidden="true">3.</strong> Naive example</a></li><li><a href="0_3_proper_waker.html"><strong aria-hidden="true">4.</strong> Proper Waker</a></li><li><a href="0_4_proper_future.html"><strong aria-hidden="true">5.</strong> Proper Future</a></li><li><a href="0_5_async_wait.html"><strong aria-hidden="true">6.</strong> Supporting async/await</a></li><li><a href="0_6_concurrent_futures.html"><strong aria-hidden="true">7.</strong> Bonus: concurrent futures</a></li></ol>
|
|
</div>
|
|
<div id="sidebar-resize-handle" class="sidebar-resize-handle"></div>
|
|
</nav>
|
|
|
|
<div id="page-wrapper" class="page-wrapper">
|
|
|
|
<div class="page">
|
|
|
|
<div id="menu-bar" class="menu-bar">
|
|
<div id="menu-bar-sticky-container">
|
|
<div class="left-buttons">
|
|
<button id="sidebar-toggle" class="icon-button" type="button" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
|
<i class="fa fa-bars"></i>
|
|
</button>
|
|
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
|
<i class="fa fa-paint-brush"></i>
|
|
</button>
|
|
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
|
<li role="none"><button role="menuitem" class="theme" id="light">Light (default)</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
|
</ul>
|
|
|
|
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
|
<i class="fa fa-search"></i>
|
|
</button>
|
|
|
|
</div>
|
|
|
|
<h1 class="menu-title">Futures Explained in 200 Lines of Rust</h1>
|
|
|
|
<div class="right-buttons">
|
|
<a href="print.html" title="Print this book" aria-label="Print this book">
|
|
<i id="print-button" class="fa fa-print"></i>
|
|
</a>
|
|
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
<div id="search-wrapper" class="hidden">
|
|
<form id="searchbar-outer" class="searchbar-outer">
|
|
<input type="search" name="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
|
</form>
|
|
<div id="searchresults-outer" class="searchresults-outer hidden">
|
|
<div id="searchresults-header" class="searchresults-header"></div>
|
|
<ul id="searchresults">
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
|
<script type="text/javascript">
|
|
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
|
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
|
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
|
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
|
});
|
|
</script>
|
|
|
|
<div id="content" class="content">
|
|
<main>
|
|
<h1><a class="header" href="#futures-explained-in-200-lines-of-rust" id="futures-explained-in-200-lines-of-rust">Futures Explained in 200 Lines of Rust</a></h1>
|
|
<p>This book aims to explain <code>Futures</code> in Rust using an example driven approach.</p>
|
|
<p>The goal is to get a better understanding of <code>Futures</code> by implementing a toy
|
|
<code>Reactor</code>, a very simple <code>Executor</code> and our own <code>Futures</code>. </p>
|
|
<p>We'll start off solving a small problem without <code>Futures</code>, <code>Wakers</code> or async/await
|
|
and then gradually adapt our example so it implements all these concepts, and
|
|
can be solved using the executor provided by both <code>tokio</code> and <code>async_str</code>.</p>
|
|
<p>In the end I've made some reader excercises you can do if you want to fix some
|
|
of the most glaring ommissions and shortcuts we took and create a slightly better
|
|
example yourself.</p>
|
|
<h2><a class="header" href="#what-does-this-book-give-you-that-isnt-covered-elsewhere" id="what-does-this-book-give-you-that-isnt-covered-elsewhere">What does this book give you that isn't covered elsewhere?</a></h2>
|
|
<p>That's a valid question. There are many good resources and examples already. First
|
|
of all, this book will point you to some background information that I have found
|
|
very valuable to get an understanding of concurrent programming in general.</p>
|
|
<p>I find that many discussions arise, not because <code>Futures</code> is a hard concept to
|
|
grasp, but that concurrent programming is a hard concept in general.</p>
|
|
<p>Secondly, I've always found small runnable examples very exiting to learn from. It's
|
|
all code that you can download, play with and learn from.</p>
|
|
<h2><a class="header" href="#what-well-do-and-not" id="what-well-do-and-not">What we'll do and not</a></h2>
|
|
<p><strong>We'll:</strong></p>
|
|
<ul>
|
|
<li>Implement our own <code>Futures</code> and get to know the <code>Reactor/Executor</code> pattern</li>
|
|
<li>Implement our own waker and learn why it's a bit foreign compared to other types</li>
|
|
<li>Talk a bit about runtime complexity and what to keep in mind when writing async Rust.</li>
|
|
<li>Make sure all examples can be run on the playground</li>
|
|
<li>Not rely on any helpers or libraries, but try to face the complexity and learn</li>
|
|
</ul>
|
|
<p><strong>We'll not:</strong></p>
|
|
<ul>
|
|
<li>Talk about how futures are implemented in Rust the language, the state machine and so on</li>
|
|
<li>Explain how the different runtimes differ, however, you'll hopefully be a bit
|
|
better off if you read this before you go research them</li>
|
|
<li>Explain concurrent programming, but I will supply sources</li>
|
|
</ul>
|
|
<p>I do want to explore Rusts internal implementation but that will be for a later
|
|
book.</p>
|
|
<h2><a class="header" href="#credits-and-thanks" id="credits-and-thanks">Credits and thanks</a></h2>
|
|
<p>I'll like to take the chance of thanking the people behind <code>mio</code>, <code>tokio</code>,
|
|
<code>async_std</code>, <code>Futures</code>, <code>libc</code>, <code>crossbeam</code> and many other libraries which so
|
|
much is built upon. Reading and exploring some of this code is nothing less than
|
|
impressive.</p>
|
|
<h2><a class="header" href="#why-is-futures-in-rust-hard-to-understand" id="why-is-futures-in-rust-hard-to-understand">Why is <code>Futures</code> in Rust hard to understand</a></h2>
|
|
<p>Well, I think it has to do with several things:</p>
|
|
<ol>
|
|
<li>
|
|
<p>Futures has a very interesting implementation, compiling down to a state
|
|
machine using generators to suspend and resume execution. In a language such as
|
|
Rust this is pretty hard to do ergonomically and safely. You are exposed to some
|
|
if this complexity when working with futures and want to understand them, not
|
|
only learn how to use them.</p>
|
|
</li>
|
|
<li>
|
|
<p>Rust doesn't provide a runtime. That means you'll actually have to choose one
|
|
yourself and actually know what a <code>Reactor</code> and an <code>Executor</code> is. While not
|
|
too difficult, you need to make more choices than you need in GO and other
|
|
languages designed with a concurrent programming in mind and ships with a
|
|
runtime.</p>
|
|
</li>
|
|
<li>
|
|
<p>Futures exist in two versions, Futures 1.0 and Futures 3.0. Futures 1.0 was
|
|
known to have some issues regarding ergonomics. Turns out that modelling
|
|
async coding after <code>Promises</code> in JavaScript can turn in to extremely long errors
|
|
and type signatures with a type system as Rust.</p>
|
|
</li>
|
|
</ol>
|
|
<p>Futures 3.0 are not compatible with Futures 1.0 without performing some work.</p>
|
|
<ol start="4">
|
|
<li>Async await syntax was recently stabilized</li>
|
|
</ol>
|
|
<p>what we'll
|
|
really do is to stub out a <code>Reactor</code>, and <code>Executor</code> and implement</p>
|
|
<h1><a class="header" href="#some-background-information" id="some-background-information">Some background information</a></h1>
|
|
<p>Before we start implementing our <code>Futures</code> , we'll go through some background
|
|
information that will help demystify some of the concepts we encounter.</p>
|
|
<h2><a class="header" href="#concurrency-in-general" id="concurrency-in-general">Concurrency in general</a></h2>
|
|
<p>If you find the concepts of concurrency and async programming confusing in
|
|
general, I know where you're coming from and I have written some resources to
|
|
try to give a high level overview that will make it easier to learn Rusts
|
|
<code>Futures</code> afterwards:</p>
|
|
<ul>
|
|
<li><a href="https://cfsamson.github.io/book-exploring-async-basics/1_concurrent_vs_parallel.html">Async Basics - The difference between concurrency and parallelism</a></li>
|
|
<li><a href="https://cfsamson.github.io/book-exploring-async-basics/2_async_history.html">Async Basics - Async history</a></li>
|
|
<li><a href="https://cfsamson.github.io/book-exploring-async-basics/5_strategies_for_handling_io.html">Async Basics - Strategies for handling I/O</a></li>
|
|
<li><a href="https://cfsamson.github.io/book-exploring-async-basics/6_epoll_kqueue_iocp.html">Async Basics - Epoll, Kqueue and IOCP</a></li>
|
|
</ul>
|
|
<h1><a class="header" href="#trait-objects-and-fat-pointers" id="trait-objects-and-fat-pointers">Trait objects and fat pointers</a></h1>
|
|
<h2><a class="header" href="#trait-objects-and-dynamic-dispatch" id="trait-objects-and-dynamic-dispatch">Trait objects and dynamic dispatch</a></h2>
|
|
<p>The single most confusing topic we encounter when implementing our own <code>Futures</code>
|
|
is how we implement a <code>Waker</code> . Creating a <code>Waker</code> involves creating a <code>vtable</code>
|
|
which allows using dynamic dispatch to call methods on a <em>type erased</em> trait
|
|
object we construct our selves.</p>
|
|
<p>If you want to know more about dynamic dispatch in Rust I can recommend this article:</p>
|
|
<p>https://alschwalm.com/blog/static/2017/03/07/exploring-dynamic-dispatch-in-rust/</p>
|
|
<p>Let's explain this a bit more in detail.</p>
|
|
<h2><a class="header" href="#fat-pointers-in-rust" id="fat-pointers-in-rust">Fat pointers in Rust</a></h2>
|
|
<p>Let's take a look at the size of some different pointer types in Rust. If we
|
|
run the following code:</p>
|
|
<pre><pre class="playpen"><code class="language-rust"># use std::mem::size_of;
|
|
trait SomeTrait { }
|
|
|
|
fn main() {
|
|
println!("Size of Box<i32>: {}", size_of::<Box<i32>>());
|
|
println!("Size of &i32: {}", size_of::<&i32>());
|
|
println!("Size of &Box<i32>: {}", size_of::<&Box<i32>>());
|
|
println!("Size of Box<Trait>: {}", size_of::<Box<SomeTrait>>());
|
|
println!("Size of &dyn Trait: {}", size_of::<&dyn SomeTrait>());
|
|
println!("Size of &[i32]: {}", size_of::<&[i32]>());
|
|
println!("Size of &[&dyn Trait]: {}", size_of::<&[&dyn SomeTrait]>());
|
|
println!("Size of [i32; 10]: {}", size_of::<[i32; 10]>());
|
|
println!("Size of [&dyn Trait; 10]: {}", size_of::<[&dyn SomeTrait; 10]>());
|
|
}
|
|
</code></pre></pre>
|
|
<p>As you see from the output after running this, the sizes of the references varies.
|
|
Most are 8 bytes (which is a pointer size on 64 bit systems), but some are 16
|
|
bytes.</p>
|
|
<p>The 16 byte sized pointers are called "fat pointers" since they carry more extra
|
|
information.</p>
|
|
<p><strong>In the case of <code>&[i32]</code> :</strong> </p>
|
|
<ul>
|
|
<li>The first 8 bytes is the actual pointer to the first element in the array</li>
|
|
</ul>
|
|
<p>(or part of an array the slice refers to)</p>
|
|
<ul>
|
|
<li>The second 8 bytes is the length of the slice.</li>
|
|
</ul>
|
|
<p>The one we'll concern ourselves about is the references to traits, or
|
|
<em>trait objects</em> as they're called in Rust.</p>
|
|
<p><code>&dyn SomeTrait</code> is an example of a <em>trait object</em> </p>
|
|
<p>The layout for a pointer to a <em>trait object</em> looks like this: </p>
|
|
<ul>
|
|
<li>The first 8 bytes points to the <code>data</code> for the trait object</li>
|
|
<li>The second 8 bytes points to the <code>vtable</code> for the trait object</li>
|
|
</ul>
|
|
<p>The reason for this is to allow us to refer to an object we know nothing about
|
|
except that it implements the methods defined by our trait. To allow this we use
|
|
dynamic dispatch.</p>
|
|
<p>Let's explain this in code instead of words by implementing our own trait
|
|
object from these parts:</p>
|
|
<pre><pre class="playpen"><code class="language-rust">// A reference to a trait object is a fat pointer: (data_ptr, vtable_ptr)
|
|
trait Test {
|
|
fn add(&self) -> i32;
|
|
fn sub(&self) -> i32;
|
|
fn mul(&self) -> i32;
|
|
}
|
|
|
|
// This will represent our home brewn fat pointer to a trait object
|
|
#[repr(C)]
|
|
struct FatPointer<'a> {
|
|
/// A reference is a pointer to an instantiated `Data` instance
|
|
data: &'a mut Data,
|
|
/// Since we need to pass in literal values like length and alignment it's
|
|
/// easiest for us to convert pointers to usize-integers instead of the other way around.
|
|
vtable: *const usize,
|
|
}
|
|
|
|
// This is the data in our trait object. It's just two numbers we want to operate on.
|
|
struct Data {
|
|
a: i32,
|
|
b: i32,
|
|
}
|
|
|
|
// ====== function definitions ======
|
|
fn add(s: &Data) -> i32 {
|
|
s.a + s.b
|
|
}
|
|
fn sub(s: &Data) -> i32 {
|
|
s.a - s.b
|
|
}
|
|
fn mul(s: &Data) -> i32 {
|
|
s.a * s.b
|
|
}
|
|
|
|
fn main() {
|
|
let mut data = Data {a: 3, b: 2};
|
|
// vtable is like special purpose array of pointer-length types with a fixed
|
|
// format where the three first values has a special meaning like the
|
|
// length of the array is encoded in the array itself as the second value.
|
|
let vtable = vec![
|
|
0, // pointer to `Drop` (which we're not implementing here)
|
|
6, // lenght of vtable
|
|
8, // alignment
|
|
// we need to make sure we add these in the same order as defined in the Trait.
|
|
// Try changing the order of add and sub and see what happens.
|
|
add as usize, // function pointer
|
|
sub as usize, // function pointer
|
|
mul as usize, // function pointer
|
|
];
|
|
|
|
let fat_pointer = FatPointer { data: &mut data, vtable: vtable.as_ptr()};
|
|
let test = unsafe { std::mem::transmute::<FatPointer, &dyn Test>(fat_pointer) };
|
|
|
|
// And voalá, it's now a trait object we can call methods on
|
|
println!("Add: 3 + 2 = {}", test.add());
|
|
println!("Sub: 3 - 2 = {}", test.sub());
|
|
println!("Mul: 3 * 2 = {}", test.mul());
|
|
}
|
|
|
|
</code></pre></pre>
|
|
<p>If you run this code by pressing the "play" button at the top you'll se it
|
|
outputs just what we expect.</p>
|
|
<p>This code example is editable so you can change it
|
|
and run it to see what happens.</p>
|
|
<p>The reason we go through this will be clear later on when we implement our own
|
|
<code>Waker</code> we'll actually set up a <code>vtable</code> like we do here to and knowing what
|
|
it is will make this much less mysterious.</p>
|
|
<h2><a class="header" href="#reactorexecutor-pattern" id="reactorexecutor-pattern">Reactor/Executor pattern</a></h2>
|
|
<p>If you don't know what this is, you should take a few minutes and read about
|
|
it. You will encounter the term <code>Reactor</code> and <code>Executor</code> a lot when working
|
|
with async code in Rust.</p>
|
|
<p>I have written a quick introduction explaining this pattern before which you
|
|
can take a look at here:</p>
|
|
<p><a href="https://cfsamsonbooks.gitbook.io/epoll-kqueue-iocp-explained/appendix-1/reactor-executor-pattern"><img src="./assets/reactorexecutor.png" alt="homepage" /></a></p>
|
|
<div style="text-align:center">
|
|
<a href="https://cfsamsonbooks.gitbook.io/epoll-kqueue-iocp-explained/appendix-1/reactor-executor-pattern">Epoll, Kqueue and IOCP Explained - The Reactor-Executor Pattern</a>
|
|
</div>
|
|
<p>I'll re-iterate the most important parts here.</p>
|
|
<p>This pattern consists of at least 2 parts:</p>
|
|
<ol>
|
|
<li>A reactor
|
|
<ul>
|
|
<li>handles some kind of event queue</li>
|
|
<li>has the responsibility of respoonding to events</li>
|
|
</ul>
|
|
</li>
|
|
<li>An executor
|
|
<ul>
|
|
<li>Often has a scheduler</li>
|
|
<li>Holds a set of suspended tasks, and has the responsibility of resuming
|
|
them when an event has occurred</li>
|
|
</ul>
|
|
</li>
|
|
<li>The concept of a task
|
|
<ul>
|
|
<li>A set of operations that can be stopped half way and resumed later on</li>
|
|
</ul>
|
|
</li>
|
|
</ol>
|
|
<p>This is a pattern not only used in Rust, but it's very popular in Rust due to
|
|
how well it separates concerns between handling and scheduling tasks, and queing
|
|
and responding to I/O events.</p>
|
|
<p>The only thing Rust as a language defines is the <em>task</em>. In Rust we call an
|
|
incorruptible task a <code>Future</code>. Futures has a well defined interface, which means
|
|
they can be used across the entire ecosystem.</p>
|
|
<p>In addition, Rust provides a way for the Reactor and Executor to communicate
|
|
through the <code>Waker</code>. We'll get to know these in the following chapters.</p>
|
|
<p>Providing these pieces let's Rust take care a lot of the ergonomic "friction"
|
|
programmers meet when faced with async code, and still not dictate any
|
|
preferred runtime to actually do the scheduling and I/O queues.</p>
|
|
<p>It's important to know that Rust doesn't provide a runtime, so you have to choose
|
|
one. <a href="https://github.com/async-rs/async-std">async std</a> and <a href="https://github.com/tokio-rs/tokio">tokio</a> are two popular ones.</p>
|
|
<p>With that out of the way, let's move on to our main example.</p>
|
|
<h1><a class="header" href="#generators-and-pin" id="generators-and-pin">Generators and Pin</a></h1>
|
|
<p>So the second difficult part that there seems to be a lot of questions about
|
|
is Generators and the <code>Pin</code> type.</p>
|
|
<h2><a class="header" href="#generators" id="generators">Generators</a></h2>
|
|
<pre><code>**Relevant for:**
|
|
|
|
- Understanding how the async/await syntax works
|
|
- Why we need `Pin`
|
|
- Why Rusts async model is extremely efficient
|
|
</code></pre>
|
|
<p>The motivation for <code>Generators</code> can be found in <a href="https://github.com/rust-lang/rfcs/blob/master/text/2033-experimental-coroutines.md">RFC#2033</a>. It's very
|
|
well written and I can recommend reading through it (it talks as much about
|
|
async/await as it does about generators).</p>
|
|
<p>Basically, there were three main options that were discussed when Rust was
|
|
desiging how the language would handle concurrency:</p>
|
|
<ol>
|
|
<li>Stackful coroutines, better known as green threads.</li>
|
|
<li>Using combinators.</li>
|
|
<li>Stackless coroutines, better known as generators.</li>
|
|
</ol>
|
|
<h3><a class="header" href="#stackful-coroutinesgreen-threads" id="stackful-coroutinesgreen-threads">Stackful coroutines/green threads</a></h3>
|
|
<p>I've written about green threads before. Go check out
|
|
<a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/">Green Threads Explained in 200 lines of Rust</a> if you're interested.</p>
|
|
<p>Green threads uses the same mechanisms as an OS does by creating a thread for
|
|
each task, setting up a stack and forcing the CPU to save it's state and jump
|
|
from one task(thread) to another. We yield control to the scheduler which then
|
|
continues running a different task.</p>
|
|
<p>Rust had green threads once, but they were removed before it hit 1.0. The state
|
|
of execution is stored in each stack so in such a solution there would be no need
|
|
for <code>async</code>, <code>await</code>, <code>Futures</code> or <code>Pin</code>. All this would be implementation
|
|
details for the library.</p>
|
|
<h3><a class="header" href="#combinators" id="combinators">Combinators</a></h3>
|
|
<p><code>Futures 1.0</code> used combinators. If you've worked with <code>Promises</code> in JavaScript,
|
|
you already know combinators. In Rust they look like this:</p>
|
|
<pre><pre class="playpen"><code class="language-rust">
|
|
# #![allow(unused_variables)]
|
|
#fn main() {
|
|
let future = Connection::connect(conn_str).and_then(|conn| {
|
|
conn.query("somerequest").map(|row|{
|
|
SomeStruct::from(row)
|
|
}).collect::<Vec<SomeStruct>>()
|
|
});
|
|
|
|
let rows: Result<Vec<SomeStruct>, SomeLibraryError> = block_on(future).unwrap();
|
|
|
|
#}</code></pre></pre>
|
|
<p>While an effective solution there are mainly two downsides I'll focus on:</p>
|
|
<ol>
|
|
<li>The error messages produced could be extremely long and arcane</li>
|
|
<li>Not optimal memory usage</li>
|
|
</ol>
|
|
<p>The reason for the higher than optimal memory usage is that this is basically
|
|
a callback-based approach, where each closure stores all the data it needs
|
|
for computation. This means that as we chain these, the memory required to store
|
|
the needed state increases with each added step.</p>
|
|
<h3><a class="header" href="#stackless-coroutinesgenerators" id="stackless-coroutinesgenerators">Stackless coroutines/generators</a></h3>
|
|
<p>This is the model used in Async/Await today. It has two advantages:</p>
|
|
<ol>
|
|
<li>It's easy to convert normal Rust code to a stackless corotuine using using
|
|
async/await as keywords (it can even be done using a macro).</li>
|
|
<li>It uses memory very efficiently</li>
|
|
</ol>
|
|
<p>The second point is in contrast to <code>Futures 1.0</code> (well, both are efficient in
|
|
practice but thats beside the point). Generators are implemented as state
|
|
machines. The memory footprint of a chain of computations is only defined by
|
|
the largest footprint any single step requires. That means that adding steps to
|
|
a chain of computations might not require any added memory at all.</p>
|
|
<h2><a class="header" href="#how-generators-work" id="how-generators-work">How generators work</a></h2>
|
|
<p>In Nightly Rust today you can use the <code>yield</code> keyword. Basically using this
|
|
keyword in a closure, converts it to a generator. A closure looking like this
|
|
(I'm going to use the terminology that's currently in Rust):</p>
|
|
<pre><pre class="playpen"><code class="language-rust">
|
|
# #![allow(unused_variables)]
|
|
#fn main() {
|
|
let a = 4;
|
|
let b = move || {
|
|
println!("Hello");
|
|
yield a * 2;
|
|
println!("world!");
|
|
};
|
|
|
|
if let GeneratorState::Yielded(n) = gen.resume() {
|
|
println!("Got value {}", n);
|
|
}
|
|
|
|
if let GeneratorState::Complete(()) = gen.resume() {
|
|
()
|
|
};
|
|
#}</code></pre></pre>
|
|
<p>Early on, before there was a consensus about the design of <code>Pin</code>, this
|
|
compiled to something looking similar to this:</p>
|
|
<pre><pre class="playpen"><code class="language-rust">fn main() {
|
|
let mut gen = GeneratorA::start(4);
|
|
|
|
if let GeneratorState::Yielded(n) = gen.resume() {
|
|
println!("Got value {}", n);
|
|
}
|
|
|
|
if let GeneratorState::Complete(()) = gen.resume() {
|
|
()
|
|
};
|
|
}
|
|
|
|
// If you've ever wondered why the parameters are called Y and R the naming from
|
|
// the original rfc most likely holds the answer
|
|
enum GeneratorState<Y, R> {
|
|
// originally called `CoResult`
|
|
Yielded(Y), // originally called `Yield(Y)`
|
|
Complete(R), // originally called `Return(R)`
|
|
}
|
|
|
|
trait Generator {
|
|
type Yield;
|
|
type Return;
|
|
fn resume(&mut self) -> GeneratorState<Self::Yield, Self::Return>;
|
|
}
|
|
|
|
enum GeneratorA {
|
|
Enter(i32),
|
|
Yield1(i32),
|
|
Exit,
|
|
}
|
|
|
|
impl GeneratorA {
|
|
fn start(a1: i32) -> Self {
|
|
GeneratorA::Enter(a1)
|
|
}
|
|
}
|
|
|
|
impl Generator for GeneratorA {
|
|
type Yield = i32;
|
|
type Return = ();
|
|
fn resume(&mut self) -> GeneratorState<Self::Yield, Self::Return> {
|
|
// lets us get ownership over current state
|
|
match std::mem::replace(&mut *self, GeneratorA::Exit) {
|
|
GeneratorA::Enter(a1) => {
|
|
|
|
/*|---code before yield1---|*/
|
|
/*|*/ println!("Hello"); /*|*/
|
|
/*|*/ let a = a1 * 2; /*|*/
|
|
/*|------------------------|*/
|
|
|
|
*self = GeneratorA::Yield1(a);
|
|
GeneratorState::Yielded(a)
|
|
}
|
|
GeneratorA::Yield1(_) => {
|
|
|
|
/*|----code after yield1----|*/
|
|
/*|*/ println!("world!"); /*|*/
|
|
/*|-------------------------|*/
|
|
|
|
*self = GeneratorA::Exit;
|
|
GeneratorState::Complete(())
|
|
}
|
|
GeneratorA::Exit => panic!("Can't advance an exited generator!"),
|
|
}
|
|
}
|
|
}
|
|
</code></pre></pre>
|
|
<blockquote>
|
|
<p>The <code>yield</code> keyword was discussed first in <a href="https://github.com/rust-lang/rfcs/pull/1823">RFC#1823</a> and in <a href="https://github.com/rust-lang/rfcs/pull/1832">RFC#1832</a>.</p>
|
|
</blockquote>
|
|
<pre><code>|| {
|
|
let arr: Vec<i32> = (0..a).enumerate().map((i,_) i).collect();
|
|
for n in arr {
|
|
yield n;
|
|
}
|
|
println!("The sum is: {}", arr.iter().sum());
|
|
}
|
|
|| {
|
|
yield a * 2;
|
|
println!("Hello!");
|
|
}
|
|
</code></pre>
|
|
<h1><a class="header" href="#naive-example" id="naive-example">Naive example</a></h1>
|
|
<pre><pre class="playpen"><code class="language-rust">use std::sync::atomic::{AtomicUsize, Ordering};
|
|
use std::sync::mpsc::{channel, Sender};
|
|
use std::sync::{Arc, Mutex};
|
|
use std::thread::{self, JoinHandle};
|
|
use std::time::{Duration, Instant};
|
|
|
|
fn main() {
|
|
let readylist = Arc::new(Mutex::new(vec![]));
|
|
let mut reactor = Reactor::new();
|
|
|
|
let mywaker = MyWaker::new(1, thread::current(), readylist.clone());
|
|
reactor.register(2, mywaker);
|
|
|
|
let mywaker = MyWaker::new(2, thread::current(), readylist.clone());
|
|
reactor.register(2, mywaker);
|
|
|
|
executor_run(reactor, readylist);
|
|
}
|
|
// ====== EXECUTOR ======
|
|
fn executor_run(mut reactor: Reactor, rl: Arc<Mutex<Vec<usize>>>) {
|
|
let start = Instant::now();
|
|
loop {
|
|
let mut rl_locked = rl.lock().unwrap();
|
|
while let Some(event) = rl_locked.pop() {
|
|
let dur = (Instant::now() - start).as_secs_f32();
|
|
println!("Event {} just happened at time: {:.2}.", event, dur);
|
|
reactor.outstanding.fetch_sub(1, Ordering::Relaxed);
|
|
}
|
|
drop(rl_locked);
|
|
|
|
if reactor.outstanding.load(Ordering::Relaxed) == 0 {
|
|
reactor.close();
|
|
break;
|
|
}
|
|
|
|
thread::park();
|
|
}
|
|
}
|
|
|
|
// ====== "FUTURE" IMPL ======
|
|
#[derive(Debug)]
|
|
struct MyWaker {
|
|
id: usize,
|
|
thread: thread::Thread,
|
|
readylist: Arc<Mutex<Vec<usize>>>,
|
|
}
|
|
|
|
impl MyWaker {
|
|
fn new(id: usize, thread: thread::Thread, readylist: Arc<Mutex<Vec<usize>>>) -> Self {
|
|
MyWaker {
|
|
id,
|
|
thread,
|
|
readylist,
|
|
}
|
|
}
|
|
|
|
fn wake(&self) {
|
|
self.readylist.lock().map(|mut rl| rl.push(self.id)).unwrap();
|
|
self.thread.unpark();
|
|
}
|
|
}
|
|
|
|
|
|
#[derive(Debug, Clone)]
|
|
pub struct Task {
|
|
id: usize,
|
|
pending: bool,
|
|
}
|
|
|
|
// ===== REACTOR =====
|
|
struct Reactor {
|
|
dispatcher: Sender<Event>,
|
|
handle: Option<JoinHandle<()>>,
|
|
outstanding: AtomicUsize,
|
|
}
|
|
#[derive(Debug)]
|
|
enum Event {
|
|
Close,
|
|
Simple(MyWaker, u64),
|
|
}
|
|
|
|
impl Reactor {
|
|
fn new() -> Self {
|
|
let (tx, rx) = channel::<Event>();
|
|
let mut handles = vec![];
|
|
let handle = thread::spawn(move || {
|
|
// This simulates some I/O resource
|
|
for event in rx {
|
|
match event {
|
|
Event::Close => break,
|
|
Event::Simple(mywaker, duration) => {
|
|
let event_handle = thread::spawn(move || {
|
|
thread::sleep(Duration::from_secs(duration));
|
|
mywaker.wake();
|
|
});
|
|
handles.push(event_handle);
|
|
}
|
|
}
|
|
}
|
|
|
|
for handle in handles {
|
|
handle.join().unwrap();
|
|
}
|
|
});
|
|
|
|
Reactor {
|
|
dispatcher: tx,
|
|
handle: Some(handle),
|
|
outstanding: AtomicUsize::new(0),
|
|
}
|
|
}
|
|
|
|
fn register(&mut self, duration: u64, mywaker: MyWaker) {
|
|
self.dispatcher
|
|
.send(Event::Simple(mywaker, duration))
|
|
.unwrap();
|
|
self.outstanding.fetch_add(1, Ordering::Relaxed);
|
|
}
|
|
|
|
fn close(&mut self) {
|
|
self.dispatcher.send(Event::Close).unwrap();
|
|
}
|
|
}
|
|
|
|
impl Drop for Reactor {
|
|
fn drop(&mut self) {
|
|
self.handle.take().map(|h| h.join().unwrap()).unwrap();
|
|
}
|
|
}
|
|
</code></pre></pre>
|
|
<pre><pre class="playpen"><code class="language-rust">use std::sync::atomic::{AtomicUsize, Ordering};
|
|
use std::sync::mpsc::{channel, Sender};
|
|
use std::sync::{Arc, Mutex};
|
|
use std::thread::{self, JoinHandle};
|
|
use std::time::{Duration, Instant};
|
|
|
|
fn main() {
|
|
let readylist = Arc::new(Mutex::new(vec![]));
|
|
let mut reactor = Reactor::new();
|
|
|
|
let mywaker = MyWaker::new(1, thread::current(), readylist.clone());
|
|
reactor.register(2, mywaker);
|
|
|
|
let mywaker = MyWaker::new(2, thread::current(), readylist.clone());
|
|
reactor.register(2, mywaker);
|
|
|
|
executor_run(reactor, readylist);
|
|
}
|
|
# // ====== EXECUTOR ======
|
|
# fn executor_run(mut reactor: Reactor, rl: Arc<Mutex<Vec<usize>>>) {
|
|
# let start = Instant::now();
|
|
# loop {
|
|
# let mut rl_locked = rl.lock().unwrap();
|
|
# while let Some(event) = rl_locked.pop() {
|
|
# let dur = (Instant::now() - start).as_secs_f32();
|
|
# println!("Event {} just happened at time: {:.2}.", event, dur);
|
|
# reactor.outstanding.fetch_sub(1, Ordering::Relaxed);
|
|
# }
|
|
# drop(rl_locked);
|
|
#
|
|
# if reactor.outstanding.load(Ordering::Relaxed) == 0 {
|
|
# reactor.close();
|
|
# break;
|
|
# }
|
|
#
|
|
# thread::park();
|
|
# }
|
|
# }
|
|
#
|
|
# // ====== "FUTURE" IMPL ======
|
|
# #[derive(Debug)]
|
|
# struct MyWaker {
|
|
# id: usize,
|
|
# thread: thread::Thread,
|
|
# readylist: Arc<Mutex<Vec<usize>>>,
|
|
# }
|
|
#
|
|
# impl MyWaker {
|
|
# fn new(id: usize, thread: thread::Thread, readylist: Arc<Mutex<Vec<usize>>>) -> Self {
|
|
# MyWaker {
|
|
# id,
|
|
# thread,
|
|
# readylist,
|
|
# }
|
|
# }
|
|
#
|
|
# fn wake(&self) {
|
|
# self.readylist.lock().map(|mut rl| rl.push(self.id)).unwrap();
|
|
# self.thread.unpark();
|
|
# }
|
|
# }
|
|
#
|
|
#
|
|
# #[derive(Debug, Clone)]
|
|
# pub struct Task {
|
|
# id: usize,
|
|
# pending: bool,
|
|
# }
|
|
#
|
|
# // ===== REACTOR =====
|
|
# struct Reactor {
|
|
# dispatcher: Sender<Event>,
|
|
# handle: Option<JoinHandle<()>>,
|
|
# outstanding: AtomicUsize,
|
|
# }
|
|
# #[derive(Debug)]
|
|
# enum Event {
|
|
# Close,
|
|
# Simple(MyWaker, u64),
|
|
# }
|
|
#
|
|
# impl Reactor {
|
|
# fn new() -> Self {
|
|
# let (tx, rx) = channel::<Event>();
|
|
# let mut handles = vec![];
|
|
# let handle = thread::spawn(move || {
|
|
# // This simulates some I/O resource
|
|
# for event in rx {
|
|
# match event {
|
|
# Event::Close => break,
|
|
# Event::Simple(mywaker, duration) => {
|
|
# let event_handle = thread::spawn(move || {
|
|
# thread::sleep(Duration::from_secs(duration));
|
|
# mywaker.wake();
|
|
# });
|
|
# handles.push(event_handle);
|
|
# }
|
|
# }
|
|
# }
|
|
#
|
|
# for handle in handles {
|
|
# handle.join().unwrap();
|
|
# }
|
|
# });
|
|
#
|
|
# Reactor {
|
|
# dispatcher: tx,
|
|
# handle: Some(handle),
|
|
# outstanding: AtomicUsize::new(0),
|
|
# }
|
|
# }
|
|
#
|
|
# fn register(&mut self, duration: u64, mywaker: MyWaker) {
|
|
# self.dispatcher
|
|
# .send(Event::Simple(mywaker, duration))
|
|
# .unwrap();
|
|
# self.outstanding.fetch_add(1, Ordering::Relaxed);
|
|
# }
|
|
#
|
|
# fn close(&mut self) {
|
|
# self.dispatcher.send(Event::Close).unwrap();
|
|
# }
|
|
# }
|
|
#
|
|
# impl Drop for Reactor {
|
|
# fn drop(&mut self) {
|
|
# self.handle.take().map(|h| h.join().unwrap()).unwrap();
|
|
# }
|
|
# }
|
|
</code></pre></pre>
|
|
<h1><a class="header" href="#proper-waker" id="proper-waker">Proper Waker</a></h1>
|
|
<h1><a class="header" href="#proper-future" id="proper-future">Proper Future</a></h1>
|
|
<h1><a class="header" href="#supporting-asyncawait" id="supporting-asyncawait">Supporting async/await</a></h1>
|
|
<h1><a class="header" href="#bonus-concurrent-futures" id="bonus-concurrent-futures">Bonus: concurrent futures</a></h1>
|
|
|
|
</main>
|
|
|
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|
<!-- Mobile navigation buttons -->
|
|
|
|
|
|
|
|
|
|
<div style="clear: both"></div>
|
|
</nav>
|
|
</div>
|
|
</div>
|
|
|
|
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
|
|
|
|
|
|
|
</nav>
|
|
|
|
</div>
|
|
|
|
|
|
<!-- Livereload script (if served using the cli tool) -->
|
|
<script type="text/javascript">
|
|
var socket = new WebSocket("ws://localhost:3001");
|
|
socket.onmessage = function (event) {
|
|
if (event.data === "reload") {
|
|
socket.close();
|
|
location.reload(true); // force reload from server (not from cache)
|
|
}
|
|
};
|
|
|
|
window.onbeforeunload = function() {
|
|
socket.close();
|
|
}
|
|
</script>
|
|
|
|
|
|
|
|
|
|
|
|
<script src="ace.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="editor.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="mode-rust.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="theme-dawn.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="theme-tomorrow_night.js" type="text/javascript" charset="utf-8"></script>
|
|
|
|
|
|
|
|
<script src="elasticlunr.min.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="mark.min.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="searcher.js" type="text/javascript" charset="utf-8"></script>
|
|
|
|
|
|
<script src="clipboard.min.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="highlight.js" type="text/javascript" charset="utf-8"></script>
|
|
<script src="book.js" type="text/javascript" charset="utf-8"></script>
|
|
|
|
<!-- Custom JS scripts -->
|
|
|
|
|
|
|
|
|
|
<script type="text/javascript">
|
|
window.addEventListener('load', function() {
|
|
window.setTimeout(window.print, 100);
|
|
});
|
|
</script>
|
|
|
|
|
|
|
|
</body>
|
|
</html>
|