1356 lines
58 KiB
HTML
1356 lines
58 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="1_0_background_information.html"><strong aria-hidden="true">2.</strong> Some background information</a></li><li><ol class="section"><li><a href="1_1_trait_objects.html"><strong aria-hidden="true">2.1.</strong> Trait objects and fat pointers</a></li><li><a href="1_2_generators_pin.html"><strong aria-hidden="true">2.2.</strong> Generators and Pin</a></li><li><a href="1_3_pin.html"><strong aria-hidden="true">2.3.</strong> Pin</a></li></ol></li><li><a href="2_0_future_example.html"><strong aria-hidden="true">3.</strong> The main example</a></li><li><a href="2_1_concurrent_futures.html"><strong aria-hidden="true">4.</strong> Bonus 1: 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>
|
|
<p>r</p>
|
|
<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>
|
|
<blockquote>
|
|
<p><strong>Relevant for:</strong></p>
|
|
<ul>
|
|
<li>Understanding how the async/await syntax works since it's how <code>await</code> is implemented</li>
|
|
<li>Why we need <code>Pin</code></li>
|
|
<li>Why Rusts async model is extremely efficient</li>
|
|
</ul>
|
|
<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>
|
|
</blockquote>
|
|
<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><code class="language-rust noplaypen ignore">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>
|
|
<p>While an effective solution there are mainly three 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>
|
|
<li>Did not allow to borrow across combinator steps.</li>
|
|
</ol>
|
|
<p>Point #3, is actually a major drawback with <code>Futures 1.0</code>.</p>
|
|
<p>Not allowing borrows across suspension points ends up being very
|
|
un-ergonomic and often requiring extra allocations or copying to accomplish
|
|
some tasks which is inefficient.</p>
|
|
<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 Rust today. It a few notable 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>No need for context switching and saving/restoring CPU state</li>
|
|
<li>No need to handle dynamic stack allocation</li>
|
|
<li>Very memory efficient</li>
|
|
<li>Allowed for borrows across suspension points</li>
|
|
</ol>
|
|
<p>The last point is in contrast to <code>Futures 1.0</code>. With async/await we can do this:</p>
|
|
<pre><code class="language-rust ignore">async fn myfn() {
|
|
let text = String::from("Hello world");
|
|
let borrowed = &text[0..5];
|
|
somefuture.await;
|
|
println!("{}", borrowed);
|
|
}
|
|
</code></pre>
|
|
<p>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><code class="language-rust noplaypen ignore">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>
|
|
<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>
|
|
<p>Now that you know that the <code>yield</code> keyword in reality rewrites your code to become a state machine,
|
|
you'll also know the basics of how <code>await</code> works. It's very similar.</p>
|
|
<p>Now, there are some limitations in our naive state machine above. What happens when you have a
|
|
<code>borrow</code> across a <code>yield</code> point?</p>
|
|
<p>We could forbid that, but <strong>one of the major design goals for the async/await syntax has been
|
|
to allow this</strong>. These kinds of borrows were not possible using <code>Futures 1.0</code> so we can't let this
|
|
limitation just slip and call it a day yet.</p>
|
|
<p>Instead of discussing it in theory, let's look at some code. </p>
|
|
<blockquote>
|
|
<p>We'll use the optimized version of the state machines which is used in Rust today. For a more
|
|
in deapth explanation see <a href="https://tmandry.gitlab.io/blog/posts/optimizing-await-1/">Tyler Mandry's execellent article: How Rust optimizes async/await</a></p>
|
|
</blockquote>
|
|
<pre><code class="language-rust noplaypen ignore">let a = 4;
|
|
let b = move || {
|
|
let to_borrow = String::new("Hello");
|
|
let borrowed = &to_borrow;
|
|
println!("{}", borrowed);
|
|
yield a * 2;
|
|
println!("{} world!", borrowed);
|
|
};
|
|
</code></pre>
|
|
<p>Now what does our rewritten state machine look like with this example?</p>
|
|
<pre><pre class="playpen"><code class="language-rust compile_fail">
|
|
# #![allow(unused_variables)]
|
|
#fn main() {
|
|
# // 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,
|
|
Yield1 {
|
|
to_borrow: String,
|
|
borrowed: &String, // uh, what lifetime should this have?
|
|
},
|
|
Exit,
|
|
}
|
|
|
|
# impl GeneratorA {
|
|
# fn start() -> Self {
|
|
# GeneratorA::Enter
|
|
# }
|
|
# }
|
|
|
|
impl Generator for GeneratorA {
|
|
type Yield = usize;
|
|
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 => {
|
|
let to_borrow = String::from("Hello");
|
|
let borrowed = &to_borrow;
|
|
*self = GeneratorA::Yield1 {to_borrow, borrowed};
|
|
GeneratorState::Yielded(borrowed.len())
|
|
}
|
|
|
|
GeneratorA::Yield1 {to_borrow, borrowed} => {
|
|
println!("Hello {}", borrowed);
|
|
*self = GeneratorA::Exit;
|
|
GeneratorState::Complete(())
|
|
}
|
|
GeneratorA::Exit => panic!("Can't advance an exited generator!"),
|
|
}
|
|
}
|
|
}
|
|
#}</code></pre></pre>
|
|
<p>If you try to compile this you'll get an error (just try it yourself by pressing play).</p>
|
|
<p>What is the lifetime of <code>&String</code>. It's not the same as the lifetime of <code>Self</code>. It's not <code>static</code>.
|
|
Turns out that it's not possible for us in Rusts syntax to describe this lifetime, which means, that
|
|
to make this work, we'll have to let the compiler know that <em>we</em> control this correct.</p>
|
|
<p>That means turning to unsafe.</p>
|
|
<p>Let's try to write an implementation that will compiler using <code>unsafe</code>. As you'll
|
|
see we end up in a <em>self referential struct</em>. A struct which holds references
|
|
into itself.</p>
|
|
<p>As you'll notice, this compiles just fine!</p>
|
|
<pre><pre class="playpen"><code class="language-rust editable">pub fn main() {
|
|
let mut gen = GeneratorA::start();
|
|
let mut gen2 = GeneratorA::start();
|
|
|
|
if let GeneratorState::Yielded(n) = gen.resume() {
|
|
println!("Got value {}", n);
|
|
}
|
|
// If you uncomment this, very bad things can happen. This is why we need `Pin`
|
|
// std::mem::swap(&mut gen, &mut gen2);
|
|
|
|
if let GeneratorState::Yielded(n) = gen2.resume() {
|
|
println!("Got value {}", n);
|
|
}
|
|
|
|
// if you uncomment `mem::swap`.. this should now start gen2.
|
|
if let GeneratorState::Complete(()) = gen.resume() {
|
|
()
|
|
};
|
|
}
|
|
|
|
enum GeneratorState<Y, R> {
|
|
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,
|
|
Yield1 {
|
|
to_borrow: String,
|
|
borrowed: *const String, // Normally you'll see `std::ptr::NonNull` used instead of *ptr
|
|
},
|
|
Exit,
|
|
}
|
|
|
|
impl GeneratorA {
|
|
fn start() -> Self {
|
|
GeneratorA::Enter
|
|
}
|
|
}
|
|
impl Generator for GeneratorA {
|
|
type Yield = usize;
|
|
type Return = ();
|
|
fn resume(&mut self) -> GeneratorState<Self::Yield, Self::Return> {
|
|
// lets us get ownership over current state
|
|
match self {
|
|
GeneratorA::Enter => {
|
|
let to_borrow = String::from("Hello");
|
|
let borrowed = &to_borrow;
|
|
let res = borrowed.len();
|
|
|
|
// Tricks to actually get a self reference
|
|
*self = GeneratorA::Yield1 {to_borrow, borrowed: std::ptr::null()};
|
|
match self {
|
|
GeneratorA::Yield1{to_borrow, borrowed} => *borrowed = to_borrow,
|
|
_ => ()
|
|
};
|
|
|
|
GeneratorState::Yielded(res)
|
|
}
|
|
|
|
GeneratorA::Yield1 {borrowed, ..} => {
|
|
let borrowed: &String = unsafe {&**borrowed};
|
|
println!("{} world", borrowed);
|
|
*self = GeneratorA::Exit;
|
|
GeneratorState::Complete(())
|
|
}
|
|
GeneratorA::Exit => panic!("Can't advance an exited generator!"),
|
|
}
|
|
}
|
|
}
|
|
</code></pre></pre>
|
|
<blockquote>
|
|
<p>Try to uncomment the line with <code>mem::swap</code> and see the result of running this code.</p>
|
|
</blockquote>
|
|
<p>While the example above compiles just fine, we expose users of this code to
|
|
both possible undefined behavior and other memory errors while using just safe
|
|
Rust. This is a big problem!</p>
|
|
<p>But now, let's prevent the segfault from happening using <code>Pin</code>. We'll discuss
|
|
<code>Pin</code> more below, but you'll get an introduction here by just reading the
|
|
comments.</p>
|
|
<pre><pre class="playpen"><code class="language-rust editable">#![feature(optin_builtin_traits)]
|
|
use std::pin::Pin;
|
|
|
|
pub fn main() {
|
|
let gen1 = GeneratorA::start();
|
|
let gen2 = GeneratorA::start();
|
|
// Before we pin the pointers, this is safe to do
|
|
// std::mem::swap(&mut gen, &mut gen2);
|
|
|
|
// constructing a `Pin::new()` on a type which does not implement `Unpin` is unsafe.
|
|
// However, as I mentioned in the start of the next chapter about `Pin` a
|
|
// boxed type automatically implements `Unpin` so to stay in safe Rust we can use
|
|
// that to avoid unsafe. You can also use crates like `pin_utils` to do this safely,
|
|
// just remember that they use unsafe under the hood so it's like using an already-reviewed
|
|
// unsafe implementation.
|
|
|
|
let mut pinned1 = Box::pin(gen1);
|
|
let mut pinned2 = Box::pin(gen2);
|
|
// Uncomment these if you think it's safe to pin the values to the stack instead
|
|
// (it is in this case). Remember to comment out the two previous lines first.
|
|
//let mut pinned1 = unsafe { Pin::new_unchecked(&mut gen1) };
|
|
//let mut pinned2 = unsafe { Pin::new_unchecked(&mut gen2) };
|
|
|
|
if let GeneratorState::Yielded(n) = pinned1.as_mut().resume() {
|
|
println!("Got value {}", n);
|
|
}
|
|
|
|
if let GeneratorState::Yielded(n) = pinned2.as_mut().resume() {
|
|
println!("Gen2 got value {}", n);
|
|
};
|
|
|
|
// This won't work
|
|
// std::mem::swap(&mut gen, &mut gen2);
|
|
// This will work but will just swap the pointers. Nothing inherently bad happens here.
|
|
// std::mem::swap(&mut pinned1, &mut pinned2);
|
|
|
|
let _ = pinned1.as_mut().resume();
|
|
let _ = pinned2.as_mut().resume();
|
|
}
|
|
|
|
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(self: Pin<&mut Self>) -> GeneratorState<Self::Yield, Self::Return>;
|
|
}
|
|
|
|
enum GeneratorA {
|
|
Enter,
|
|
Yield1 {
|
|
to_borrow: String,
|
|
borrowed: *const String, // Normally you'll see `std::ptr::NonNull` used instead of *ptr
|
|
},
|
|
Exit,
|
|
}
|
|
|
|
impl GeneratorA {
|
|
fn start() -> Self {
|
|
GeneratorA::Enter
|
|
}
|
|
}
|
|
|
|
// This tells us that the underlying pointer is not safe to move after pinning. In this case,
|
|
// only we as implementors "feel" this, however, if someone is relying on our Pinned pointer
|
|
// this will prevent them from moving it. You need to enable the feature flag
|
|
// `#![feature(optin_builtin_traits)]` and use the nightly compiler to implement `!Unpin`.
|
|
// Normally, you would use `std::marker::PhantomPinned` to indicate that the
|
|
// struct is `!Unpin`.
|
|
impl !Unpin for GeneratorA { }
|
|
|
|
impl Generator for GeneratorA {
|
|
type Yield = usize;
|
|
type Return = ();
|
|
fn resume(self: Pin<&mut Self>) -> GeneratorState<Self::Yield, Self::Return> {
|
|
// lets us get ownership over current state
|
|
let this = unsafe { self.get_unchecked_mut() };
|
|
match this {
|
|
GeneratorA::Enter => {
|
|
let to_borrow = String::from("Hello");
|
|
let borrowed = &to_borrow;
|
|
let res = borrowed.len();
|
|
|
|
// Trick to actually get a self reference. We can't reference
|
|
// the `String` earlier since these references will point to the
|
|
// location in this stack frame which will not be valid anymore
|
|
// when this function returns.
|
|
*this = GeneratorA::Yield1 {to_borrow, borrowed: std::ptr::null()};
|
|
match this {
|
|
GeneratorA::Yield1{to_borrow, borrowed} => *borrowed = to_borrow,
|
|
_ => ()
|
|
};
|
|
|
|
GeneratorState::Yielded(res)
|
|
}
|
|
|
|
GeneratorA::Yield1 {borrowed, ..} => {
|
|
let borrowed: &String = unsafe {&**borrowed};
|
|
println!("{} world", borrowed);
|
|
*this = GeneratorA::Exit;
|
|
GeneratorState::Complete(())
|
|
}
|
|
GeneratorA::Exit => panic!("Can't advance an exited generator!"),
|
|
}
|
|
}
|
|
}
|
|
</code></pre></pre>
|
|
<p>Now, as you see, the user of this code must either:</p>
|
|
<ol>
|
|
<li>Box the value and thereby allocating it on the heap</li>
|
|
<li>Use <code>unsafe</code> and pin the value to the stack. The user knows that if they move
|
|
the value afterwards it will violate the guarantee they promise to uphold when
|
|
they did their unsafe implementation.</li>
|
|
</ol>
|
|
<p>Now, the code which is created and the need for <code>Pin</code> to allow for borrowing
|
|
across <code>yield</code> points should be pretty clear. </p>
|
|
<h2><a class="header" href="#pin" id="pin">Pin</a></h2>
|
|
<blockquote>
|
|
<p><strong>Relevant for</strong></p>
|
|
<ol>
|
|
<li>To understand <code>Generators</code> and <code>Futures</code></li>
|
|
<li>Knowing how to use <code>Pin</code> is required when implementing your own <code>Future</code></li>
|
|
<li>To understand self-referential types in Rust</li>
|
|
<li>This is the way borrowing across <code>await</code> points is accomplished</li>
|
|
</ol>
|
|
<p><code>Pin</code> was suggested in <a href="https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md">RFC#2349</a></p>
|
|
</blockquote>
|
|
<p>Ping consists of the <code>Pin</code> type and the <code>Unpin</code> marker. Let's start off with some general rules:</p>
|
|
<ol>
|
|
<li>Pin does nothing special, it only prevents the user of an API to violate some assumtions you make when writing your (most likely) unsafe code.</li>
|
|
<li>Most standard library types implement <code>Unpin</code></li>
|
|
<li><code>Unpin</code> means it's OK for this type to be moved even when pinned.</li>
|
|
<li>If you <code>Box</code> a value, that boxed value automatcally implements <code>Unpin</code>.</li>
|
|
<li>The main use case for <code>Pin</code> is to allow self referential types</li>
|
|
<li>The implementation behind objects that doens't implement <code>Unpin</code> is most likely unsafe
|
|
<ol>
|
|
<li><code>Pin</code> prevents users from your code to break the assumtions you make when writing the <code>unsafe</code> implementation</li>
|
|
<li>It doesn't solve the fact that you'll have to write unsafe code to actually implement it</li>
|
|
</ol>
|
|
</li>
|
|
<li>You're not really meant to be implementing <code>!Unpin</code>, but you can on nightly with a feature flag</li>
|
|
</ol>
|
|
<blockquote>
|
|
<p>Unsafe code does not mean it's litterally "unsafe", it only relieves the
|
|
guarantees you normally get from the compiler. An <code>unsafe</code> implementation can
|
|
be perfectly safe to do, but you have no safety net.</p>
|
|
</blockquote>
|
|
<p>Let's take a look at an example:</p>
|
|
<pre><pre class="playpen"><code class="language-rust editable">use std::pin::Pin;
|
|
|
|
fn main() {
|
|
let mut test1 = Test::new("test1");
|
|
test1.init();
|
|
let mut test2 = Test::new("test2");
|
|
test2.init();
|
|
|
|
println!("a: {}, b: {}", test1.a(), test1.b());
|
|
std::mem::swap(&mut test1, &mut test2); // try commenting out this line
|
|
println!("a: {}, b: {}", test2.a(), test2.b());
|
|
|
|
}
|
|
|
|
#[derive(Debug)]
|
|
struct Test {
|
|
a: String,
|
|
b: *const String,
|
|
}
|
|
|
|
impl Test {
|
|
fn new(txt: &str) -> Self {
|
|
let a = String::from(txt);
|
|
Test {
|
|
a,
|
|
b: std::ptr::null(),
|
|
}
|
|
}
|
|
|
|
fn init(&mut self) {
|
|
let self_ref: *const String = &self.a;
|
|
self.b = self_ref;
|
|
}
|
|
|
|
fn a(&self) -> &str {
|
|
&self.a
|
|
}
|
|
|
|
fn b(&self) -> &String {
|
|
unsafe {&*(self.b)}
|
|
}
|
|
}
|
|
</code></pre></pre>
|
|
<p>As you can see this results in unwanted behavior. The pointer to <code>b</code> stays the
|
|
same and points to the old value. It's easy to get this to segfault, and fail
|
|
in other spectacular ways as well.</p>
|
|
<p>Pin essentially prevents the <strong>user</strong> of your unsafe code
|
|
(even if that means yourself) move the value after it's pinned.</p>
|
|
<p>If we change the example to using <code>Pin</code> instead:</p>
|
|
<pre><pre class="playpen"><code class="language-rust editable">use std::pin::Pin;
|
|
use std::marker::PhantomPinned;
|
|
|
|
pub fn main() {
|
|
let mut test1 = Test::new("test1");
|
|
test1.init();
|
|
let mut test1_pin = unsafe { Pin::new_unchecked(&mut test1) };
|
|
let mut test2 = Test::new("test2");
|
|
test2.init();
|
|
let mut test2_pin = unsafe { Pin::new_unchecked(&mut test2) };
|
|
|
|
println!(
|
|
"a: {}, b: {}",
|
|
Test::a(test1_pin.as_ref()),
|
|
Test::b(test1_pin.as_ref())
|
|
);
|
|
|
|
// Try to uncomment this and see what happens
|
|
// std::mem::swap(test1_pin.as_mut(), test2_pin.as_mut());
|
|
println!(
|
|
"a: {}, b: {}",
|
|
Test::a(test2_pin.as_ref()),
|
|
Test::b(test2_pin.as_ref())
|
|
);
|
|
}
|
|
|
|
#[derive(Debug)]
|
|
struct Test {
|
|
a: String,
|
|
b: *const String,
|
|
_marker: PhantomPinned,
|
|
}
|
|
|
|
|
|
impl Test {
|
|
fn new(txt: &str) -> Self {
|
|
let a = String::from(txt);
|
|
Test {
|
|
a,
|
|
b: std::ptr::null(),
|
|
// This makes our type `!Unpin`
|
|
_marker: PhantomPinned,
|
|
}
|
|
}
|
|
fn init(&mut self) {
|
|
let self_ptr: *const String = &self.a;
|
|
self.b = self_ptr;
|
|
}
|
|
|
|
fn a<'a>(self: Pin<&'a Self>) -> &'a str {
|
|
&self.get_ref().a
|
|
}
|
|
|
|
fn b<'a>(self: Pin<&'a Self>) -> &'a String {
|
|
unsafe { &*(self.b) }
|
|
}
|
|
}
|
|
|
|
</code></pre></pre>
|
|
<p>Now, what we've done here is pinning a stack address. That will always be
|
|
<code>unsafe</code> if our type implements <code>!Unpin</code>, in other words. That our type is not
|
|
<code>Unpin</code> which is the norm.</p>
|
|
<p>We use some tricks here, including requiring an <code>init</code>. If we want to fix that
|
|
and let users avoid <code>unsafe</code> we need to place our data on the heap.</p>
|
|
<p>Stack pinning will always depend on the current stack frame we're in, so we
|
|
can't create a self referential object in one stack frame and return it since
|
|
any pointers we take to "self" is invalidated.</p>
|
|
<p>The next example solves some of our friction at the cost of a heap allocation.</p>
|
|
<pre><pre class="playpen"><code class="language-rust editbable">use std::pin::Pin;
|
|
use std::marker::PhantomPinned;
|
|
|
|
pub fn main() {
|
|
let mut test1 = Test::new("test1");
|
|
let mut test2 = Test::new("test2");
|
|
|
|
println!("a: {}, b: {}",test1.as_ref().a(), test1.as_ref().b());
|
|
|
|
// Try to uncomment this and see what happens
|
|
// std::mem::swap(&mut test1, &mut test2);
|
|
println!("a: {}, b: {}",test2.as_ref().a(), test2.as_ref().b());
|
|
}
|
|
|
|
#[derive(Debug)]
|
|
struct Test {
|
|
a: String,
|
|
b: *const String,
|
|
_marker: PhantomPinned,
|
|
}
|
|
|
|
impl Test {
|
|
fn new(txt: &str) -> Pin<Box<Self>> {
|
|
let a = String::from(txt);
|
|
let t = Test {
|
|
a,
|
|
b: std::ptr::null(),
|
|
_marker: PhantomPinned,
|
|
};
|
|
let mut boxed = Box::pin(t);
|
|
let self_ptr: *const String = &boxed.as_ref().a;
|
|
unsafe { boxed.as_mut().get_unchecked_mut().b = self_ptr };
|
|
|
|
boxed
|
|
}
|
|
|
|
fn a<'a>(self: Pin<&'a Self>) -> &'a str {
|
|
&self.get_ref().a
|
|
}
|
|
|
|
fn b<'a>(self: Pin<&'a Self>) -> &'a String {
|
|
unsafe { &*(self.b) }
|
|
}
|
|
}
|
|
</code></pre></pre>
|
|
<p>Seeing this we're ready to sum up with a few more points to remember about
|
|
pinning:</p>
|
|
<ol>
|
|
<li>Pinning only makes sense to do for types that are <code>!Unpin</code></li>
|
|
<li>Pinning a <code>!Unpin</code> pointer to the stack will requires <code>unsafe</code></li>
|
|
<li>Pinning a boxed value will not require <code>unsafe</code>, even if the type is <code>!Unpin</code></li>
|
|
<li>If T: Unpin (which is the default), then Pin<'a, T> is entirely equivalent to &'a mut T.</li>
|
|
<li>Getting a <code>&mut T</code> to a pinned pointer requires unsafe if <code>T: !Unpin</code></li>
|
|
<li>Pinning is really only useful when implementing self-referential types.<br />
|
|
For all intents and purposes you can think of <code>!Unpin</code> = self-referential-type</li>
|
|
</ol>
|
|
<p>The fact that boxing (heap allocating) a value that implements <code>!Unpin</code> is safe
|
|
makes sense. Once the data is allocated on the heap it will have a stable address. </p>
|
|
<p>There are ways to safely give some guarantees on stack pinning as well, but right
|
|
now you need to use a crate like <a href="https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md">pin_utils</a>:<a href="https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md">pin_utils</a> to do that.</p>
|
|
<h3><a class="header" href="#projectionstructural-pinning" id="projectionstructural-pinning">Projection/structural pinning</a></h3>
|
|
<p>In short, projection is using a field on your type. <code>mystruct.field1</code> is a
|
|
projection. Structural pinning is using <code>Pin</code> on struct fields. This has several
|
|
caveats and is not something you'll normally see so I refer to the documentation
|
|
for that.</p>
|
|
<h3><a class="header" href="#pin-and-drop" id="pin-and-drop">Pin and Drop</a></h3>
|
|
<p>The <code>Pin</code> guarantee exists from the moment the value is pinned until it's dropped.
|
|
In the <code>Drop</code> implementation you take a mutable reference to <code>self</code>, which means
|
|
extra care must be taken when implementing <code>Drop</code> for pinned types.</p>
|
|
<h2><a class="header" href="#putting-it-all-together" id="putting-it-all-together">Putting it all together</a></h2>
|
|
<p>This is exactly what we'll do when we implement our own <code>Futures</code> stay tuned,
|
|
we're soon finished.</p>
|
|
<pre><pre class="playpen"><code class="language-rust">
|
|
use std::{
|
|
future::Future, pin::Pin, sync::{mpsc::{channel, Sender}, Arc, Mutex},
|
|
task::{Context, Poll, RawWaker, RawWakerVTable, Waker},
|
|
thread::{self, JoinHandle}, time::{Duration, Instant}
|
|
};
|
|
|
|
fn main() {
|
|
let start = Instant::now();
|
|
|
|
// Many runtimes create a glocal `reactor` we pass it as an argument
|
|
let reactor = Reactor::new();
|
|
let reactor = Arc::new(Mutex::new(reactor));
|
|
|
|
let future1 = Task::new(reactor.clone(), 2, 1);
|
|
let future2 = Task::new(reactor.clone(), 1, 2);
|
|
|
|
let fut1 = async {
|
|
let val = future1.await;
|
|
let dur = (Instant::now() - start).as_secs_f32();
|
|
println!("Future got {} at time: {:.2}.", val, dur);
|
|
};
|
|
|
|
let fut2 = async {
|
|
let val = future2.await;
|
|
let dur = (Instant::now() - start).as_secs_f32();
|
|
println!("Future got {} at time: {:.2}.", val, dur);
|
|
};
|
|
|
|
let mainfut = async {
|
|
fut1.await;
|
|
fut2.await;
|
|
};
|
|
|
|
block_on(mainfut);
|
|
reactor.lock().map(|mut r| r.close()).unwrap();
|
|
}
|
|
|
|
//// ============================ EXECUTOR ====================================
|
|
fn block_on<F: Future>(mut future: F) -> F::Output {
|
|
let mywaker = Arc::new(MyWaker{ thread: thread::current() });
|
|
let waker = waker_into_waker(Arc::into_raw(mywaker));
|
|
let mut cx = Context::from_waker(&waker);
|
|
let val = loop {
|
|
let pinned = unsafe { Pin::new_unchecked(&mut future) };
|
|
match Future::poll(pinned, &mut cx) {
|
|
Poll::Ready(val) => break val,
|
|
Poll::Pending => thread::park(),
|
|
};
|
|
};
|
|
val
|
|
}
|
|
|
|
// ====================== FUTURE IMPLEMENTATION ==============================
|
|
#[derive(Clone)]
|
|
struct MyWaker {
|
|
thread: thread::Thread,
|
|
}
|
|
|
|
#[derive(Clone)]
|
|
pub struct Task {
|
|
id: usize,
|
|
reactor: Arc<Mutex<Reactor>>,
|
|
data: u64,
|
|
is_registered: bool,
|
|
}
|
|
|
|
fn mywaker_wake(s: &MyWaker) {
|
|
let waker_ptr: *const MyWaker = s;
|
|
let waker_arc = unsafe {Arc::from_raw(waker_ptr)};
|
|
waker_arc.thread.unpark();
|
|
}
|
|
|
|
fn mywaker_clone(s: &MyWaker) -> RawWaker {
|
|
let arc = unsafe { Arc::from_raw(s).clone() };
|
|
std::mem::forget(arc.clone()); // increase ref count
|
|
RawWaker::new(Arc::into_raw(arc) as *const (), &VTABLE)
|
|
}
|
|
|
|
const VTABLE: RawWakerVTable = unsafe {
|
|
RawWakerVTable::new(
|
|
|s| mywaker_clone(&*(s as *const MyWaker)), // clone
|
|
|s| mywaker_wake(&*(s as *const MyWaker)), // wake
|
|
|s| mywaker_wake(*(s as *const &MyWaker)), // wake by ref
|
|
|s| drop(Arc::from_raw(s as *const MyWaker)), // decrease refcount
|
|
)
|
|
};
|
|
|
|
fn waker_into_waker(s: *const MyWaker) -> Waker {
|
|
let raw_waker = RawWaker::new(s as *const (), &VTABLE);
|
|
unsafe { Waker::from_raw(raw_waker) }
|
|
}
|
|
|
|
impl Task {
|
|
fn new(reactor: Arc<Mutex<Reactor>>, data: u64, id: usize) -> Self {
|
|
Task {
|
|
id,
|
|
reactor,
|
|
data,
|
|
is_registered: false,
|
|
}
|
|
}
|
|
}
|
|
|
|
impl Future for Task {
|
|
type Output = usize;
|
|
fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
|
|
let mut r = self.reactor.lock().unwrap();
|
|
if r.is_ready(self.id) {
|
|
Poll::Ready(self.id)
|
|
} else if self.is_registered {
|
|
Poll::Pending
|
|
} else {
|
|
r.register(self.data, cx.waker().clone(), self.id);
|
|
drop(r);
|
|
self.is_registered = true;
|
|
Poll::Pending
|
|
}
|
|
}
|
|
}
|
|
|
|
// =============================== REACTOR ===================================
|
|
struct Reactor {
|
|
dispatcher: Sender<Event>,
|
|
handle: Option<JoinHandle<()>>,
|
|
readylist: Arc<Mutex<Vec<usize>>>,
|
|
}
|
|
#[derive(Debug)]
|
|
enum Event {
|
|
Close,
|
|
Simple(Waker, u64, usize),
|
|
}
|
|
|
|
impl Reactor {
|
|
fn new() -> Self {
|
|
let (tx, rx) = channel::<Event>();
|
|
let readylist = Arc::new(Mutex::new(vec![]));
|
|
let rl_clone = readylist.clone();
|
|
let mut handles = vec![];
|
|
let handle = thread::spawn(move || {
|
|
// This simulates some I/O resource
|
|
for event in rx {
|
|
let rl_clone = rl_clone.clone();
|
|
match event {
|
|
Event::Close => break,
|
|
Event::Simple(waker, duration, id) => {
|
|
let event_handle = thread::spawn(move || {
|
|
thread::sleep(Duration::from_secs(duration));
|
|
rl_clone.lock().map(|mut rl| rl.push(id)).unwrap();
|
|
waker.wake();
|
|
});
|
|
|
|
handles.push(event_handle);
|
|
}
|
|
}
|
|
}
|
|
|
|
for handle in handles {
|
|
handle.join().unwrap();
|
|
}
|
|
});
|
|
|
|
Reactor {
|
|
readylist,
|
|
dispatcher: tx,
|
|
handle: Some(handle),
|
|
}
|
|
}
|
|
|
|
fn register(&mut self, duration: u64, waker: Waker, data: usize) {
|
|
self.dispatcher
|
|
.send(Event::Simple(waker, duration, data))
|
|
.unwrap();
|
|
}
|
|
|
|
fn close(&mut self) {
|
|
self.dispatcher.send(Event::Close).unwrap();
|
|
}
|
|
|
|
fn is_ready(&self, id_to_check: usize) -> bool {
|
|
self.readylist
|
|
.lock()
|
|
.map(|rl| rl.iter().any(|id| *id == id_to_check))
|
|
.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="#bonus-1-concurrent-futures" id="bonus-1-concurrent-futures">Bonus 1: 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>
|