762 lines
32 KiB
HTML
762 lines
32 KiB
HTML
<!DOCTYPE HTML>
|
|
<html lang="en" class="sidebar-visible no-js">
|
|
<head>
|
|
<!-- Book generated using mdBook -->
|
|
<meta charset="UTF-8">
|
|
<title>Background information - Futures Explained in 200 Lines of Rust</title>
|
|
|
|
|
|
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
|
|
<meta name="description" content="This book aims to explain Futures in Rust using an example driven approach.">
|
|
<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 class="affix"><a href="introduction.html">Introduction</a></li><li><a href="0_background_information.html" class="active"><strong aria-hidden="true">1.</strong> Background information</a></li><li><a href="1_futures_in_rust.html"><strong aria-hidden="true">2.</strong> Futures in Rust</a></li><li><a href="2_waker_context.html"><strong aria-hidden="true">3.</strong> Waker and Context</a></li><li><a href="3_generators_pin.html"><strong aria-hidden="true">4.</strong> Generators</a></li><li><a href="4_pin.html"><strong aria-hidden="true">5.</strong> Pin</a></li><li><a href="6_future_example.html"><strong aria-hidden="true">6.</strong> Futures - our main example</a></li><li><a href="8_finished_example.html"><strong aria-hidden="true">7.</strong> Finished example (editable)</a></li><li class="affix"><a href="conclusion.html">Conclusion and exercises</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>
|
|
|
|
<a href="https://github.com/cfsamson/books-futures-explained" title="Git repository" aria-label="Git repository">
|
|
<i id="git-repository-button" class="fa fa-github"></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="#some-background-information" id="some-background-information">Some Background Information</a></h1>
|
|
<p>Before we go into the details about Futures in Rust, let's take a quick look
|
|
at the alternatives for handling concurrent programming in general and some
|
|
pros and cons for each of them.</p>
|
|
<p>While we do that we'll get some information on concurrency which will make it
|
|
easier for us when we dive in to Futures specifically.</p>
|
|
<blockquote>
|
|
<p>For fun, I've added a small snipped of runnable code with most of the examples.
|
|
If you're like me, things get way more interesting then and maybe you'll se some
|
|
things you haven't seen before along the way.</p>
|
|
</blockquote>
|
|
<h2><a class="header" href="#threads-provided-by-the-operating-system" id="threads-provided-by-the-operating-system">Threads provided by the operating system</a></h2>
|
|
<p>Now, one way of accomplishing this is letting the OS take care of everything for
|
|
us. We do this by simply spawning a new OS thread for each task we want to
|
|
accomplish and write code like we normally would.</p>
|
|
<p>The runtime we use to handle concurrency for us is the operating system itself.</p>
|
|
<p><strong>Advantages:</strong></p>
|
|
<ul>
|
|
<li>Simple</li>
|
|
<li>Easy to use</li>
|
|
<li>Switching between tasks is reasonably fast</li>
|
|
<li>You get parallelism for free</li>
|
|
</ul>
|
|
<p><strong>Drawbacks:</strong></p>
|
|
<ul>
|
|
<li>OS level threads come with a rather large stack. If you have many tasks
|
|
waiting simultaneously (like you would in a web-server under heavy load) you'll
|
|
run out of memory pretty fast.</li>
|
|
<li>There are a lot of syscalls involved. This can be pretty costly when the number
|
|
of tasks is high.</li>
|
|
<li>The OS has many things it needs to handle. It might not switch back to your
|
|
thread as fast as you'd wish.</li>
|
|
<li>Might not be an option on some systems</li>
|
|
</ul>
|
|
<p><strong>Using OS threads in Rust looks like this:</strong></p>
|
|
<pre><pre class="playpen"><code class="language-rust">use std::thread;
|
|
|
|
fn main() {
|
|
println!("So we start the program here!");
|
|
let t1 = thread::spawn(move || {
|
|
thread::sleep(std::time::Duration::from_millis(200));
|
|
println!("We create tasks which gets run when they're finished!");
|
|
});
|
|
|
|
let t2 = thread::spawn(move || {
|
|
thread::sleep(std::time::Duration::from_millis(100));
|
|
println!("We can even chain callbacks...");
|
|
let t3 = thread::spawn(move || {
|
|
thread::sleep(std::time::Duration::from_millis(50));
|
|
println!("...like this!");
|
|
});
|
|
t3.join().unwrap();
|
|
});
|
|
println!("While our tasks are executing we can do other stuff here.");
|
|
|
|
t1.join().unwrap();
|
|
t2.join().unwrap();
|
|
}
|
|
</code></pre></pre>
|
|
<p>OS threads sure has some pretty big advantages. So why all this talk about
|
|
"async" and concurrency in the first place?</p>
|
|
<p>First of all. For computers to be <a href="https://en.wikipedia.org/wiki/Efficiency"><em>efficient</em></a> it needs to multitask. Once you
|
|
start to look under the covers (like <a href="https://os.phil-opp.com/async-await/">how an operating system works</a>)
|
|
you'll see concurrency everywhere. It's very fundamental in everything we do.</p>
|
|
<p>Secondly, we have the web. </p>
|
|
<p>Webservers is all about I/O and handling small tasks
|
|
(requests). When the number of small tasks is large it's not a good fit for OS
|
|
threads as of today because of the memory they require and the overhead involved
|
|
when creating new threads. </p>
|
|
<p>This gets even more relevant when the load is variable
|
|
which means the current number of tasks a program has at any point in time is
|
|
unpredictable. That's why you'll see so many async web frameworks and database
|
|
drivers today.</p>
|
|
<p>However, for a huge number of problems, the standard OS threads will often be the
|
|
right solution. So, just think twice about your problem before you reach for an
|
|
async library.</p>
|
|
<p>Now, let's look at some other options for multitasking. They all have in common
|
|
that they implement a way to do multitasking by having a "userland"
|
|
runtime:</p>
|
|
<h2><a class="header" href="#green-threads" id="green-threads">Green threads</a></h2>
|
|
<p>Green threads uses the same mechanism as an OS does by creating a thread for
|
|
each task, setting up a stack, save the CPU's state and jump from one
|
|
task(thread) to another by doing a "context switch".</p>
|
|
<p>We yield control to the scheduler (which is a central part of the runtime in
|
|
such a system) 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>. </p>
|
|
<p>The typical flow will be like this:</p>
|
|
<ol>
|
|
<li>Run som non-blocking code</li>
|
|
<li>Make a blocking call to some external resource</li>
|
|
<li>CPU jumps to the "main" thread which schedules a different thread to run and
|
|
"jumps" to that stack</li>
|
|
<li>Run some non-blocking code on the new thread until a new blocking call or the
|
|
task is finished</li>
|
|
<li>"jumps" back to the "main" thread, schedule a new thread to run and jump to that</li>
|
|
</ol>
|
|
<p>These "jumps" are know as <strong>context switches</strong>. Your OS is doing it many times each
|
|
second as you read this.</p>
|
|
<p><strong>Advantages:</strong></p>
|
|
<ol>
|
|
<li>Simple to use. The code will look like it does when using OS threads.</li>
|
|
<li>A "context switch" is reasonably fast</li>
|
|
<li>Each stack only gets a little memory to start with so you can have hundred of
|
|
thousands of green threads running.</li>
|
|
<li>It's easy to incorporate <a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/green-threads#preemptive-multitasking"><em>preemtion</em></a>
|
|
which puts a lot of control in the hands of the runtime implementors.</li>
|
|
</ol>
|
|
<p><strong>Drawbacks:</strong></p>
|
|
<ol>
|
|
<li>The stacks might need to grow. Solving this is not easy and will have a cost.</li>
|
|
<li>You need to save all the CPU state on every switch</li>
|
|
<li>It's not a <em>zero cost abstraction</em> (Rust had green threads early on and this
|
|
was one of the reasons they were removed).</li>
|
|
<li>Complicated to implement correctly if you want to support many different
|
|
platforms.</li>
|
|
</ol>
|
|
<p>If you were to implement green threads in Rust, it could look something like
|
|
this:</p>
|
|
<blockquote>
|
|
<p>The example presented below is an adapted example from an earlier gitbook I
|
|
wrote about green threads called <a href="https://cfsamson.gitbook.io/green-threads-explained-in-200-lines-of-rust/">Green Threads Explained in 200 lines of Rust.</a>
|
|
If you want to know what's going on you'll find everything explained in detail
|
|
in that book. The code below is wildly unsafe and it's just to show a real example.
|
|
It's not in any way meant to showcase "best practice". Just so we're on
|
|
the same page.</p>
|
|
</blockquote>
|
|
<pre><pre class="playpen"><code class="language-rust edition2018">#![feature(asm)]
|
|
#![feature(naked_functions)]
|
|
use std::ptr;
|
|
|
|
const DEFAULT_STACK_SIZE: usize = 1024 * 1024 * 2;
|
|
const MAX_THREADS: usize = 4;
|
|
static mut RUNTIME: usize = 0;
|
|
|
|
pub struct Runtime {
|
|
threads: Vec<Thread>,
|
|
current: usize,
|
|
}
|
|
|
|
#[derive(PartialEq, Eq, Debug)]
|
|
enum State {
|
|
Available,
|
|
Running,
|
|
Ready,
|
|
}
|
|
|
|
struct Thread {
|
|
id: usize,
|
|
stack: Vec<u8>,
|
|
ctx: ThreadContext,
|
|
state: State,
|
|
task: Option<Box<dyn Fn()>>,
|
|
}
|
|
|
|
#[derive(Debug, Default)]
|
|
#[repr(C)]
|
|
struct ThreadContext {
|
|
rsp: u64,
|
|
r15: u64,
|
|
r14: u64,
|
|
r13: u64,
|
|
r12: u64,
|
|
rbx: u64,
|
|
rbp: u64,
|
|
thread_ptr: u64,
|
|
}
|
|
|
|
impl Thread {
|
|
fn new(id: usize) -> Self {
|
|
Thread {
|
|
id,
|
|
stack: vec![0_u8; DEFAULT_STACK_SIZE],
|
|
ctx: ThreadContext::default(),
|
|
state: State::Available,
|
|
task: None,
|
|
}
|
|
}
|
|
}
|
|
|
|
impl Runtime {
|
|
pub fn new() -> Self {
|
|
let base_thread = Thread {
|
|
id: 0,
|
|
stack: vec![0_u8; DEFAULT_STACK_SIZE],
|
|
ctx: ThreadContext::default(),
|
|
state: State::Running,
|
|
task: None,
|
|
};
|
|
|
|
let mut threads = vec![base_thread];
|
|
threads[0].ctx.thread_ptr = &threads[0] as *const Thread as u64;
|
|
let mut available_threads: Vec<Thread> = (1..MAX_THREADS).map(|i| Thread::new(i)).collect();
|
|
threads.append(&mut available_threads);
|
|
|
|
Runtime {
|
|
threads,
|
|
current: 0,
|
|
}
|
|
}
|
|
|
|
pub fn init(&self) {
|
|
unsafe {
|
|
let r_ptr: *const Runtime = self;
|
|
RUNTIME = r_ptr as usize;
|
|
}
|
|
}
|
|
|
|
pub fn run(&mut self) -> ! {
|
|
while self.t_yield() {}
|
|
std::process::exit(0);
|
|
}
|
|
|
|
fn t_return(&mut self) {
|
|
if self.current != 0 {
|
|
self.threads[self.current].state = State::Available;
|
|
self.t_yield();
|
|
}
|
|
}
|
|
|
|
fn t_yield(&mut self) -> bool {
|
|
let mut pos = self.current;
|
|
while self.threads[pos].state != State::Ready {
|
|
pos += 1;
|
|
if pos == self.threads.len() {
|
|
pos = 0;
|
|
}
|
|
if pos == self.current {
|
|
return false;
|
|
}
|
|
}
|
|
|
|
if self.threads[self.current].state != State::Available {
|
|
self.threads[self.current].state = State::Ready;
|
|
}
|
|
|
|
self.threads[pos].state = State::Running;
|
|
let old_pos = self.current;
|
|
self.current = pos;
|
|
|
|
unsafe {
|
|
switch(&mut self.threads[old_pos].ctx, &self.threads[pos].ctx);
|
|
}
|
|
true
|
|
}
|
|
|
|
pub fn spawn<F: Fn() + 'static>(f: F){
|
|
unsafe {
|
|
let rt_ptr = RUNTIME as *mut Runtime;
|
|
let available = (*rt_ptr)
|
|
.threads
|
|
.iter_mut()
|
|
.find(|t| t.state == State::Available)
|
|
.expect("no available thread.");
|
|
|
|
let size = available.stack.len();
|
|
let s_ptr = available.stack.as_mut_ptr();
|
|
available.task = Some(Box::new(f));
|
|
available.ctx.thread_ptr = available as *const Thread as u64;
|
|
ptr::write(s_ptr.offset((size - 8) as isize) as *mut u64, guard as u64);
|
|
ptr::write(s_ptr.offset((size - 16) as isize) as *mut u64, call as u64);
|
|
available.ctx.rsp = s_ptr.offset((size - 16) as isize) as u64;
|
|
available.state = State::Ready;
|
|
}
|
|
}
|
|
}
|
|
|
|
fn call(thread: u64) {
|
|
let thread = unsafe { &*(thread as *const Thread) };
|
|
if let Some(f) = &thread.task {
|
|
f();
|
|
}
|
|
}
|
|
|
|
#[naked]
|
|
fn guard() {
|
|
unsafe {
|
|
let rt_ptr = RUNTIME as *mut Runtime;
|
|
let rt = &mut *rt_ptr;
|
|
println!("THREAD {} FINISHED.", rt.threads[rt.current].id);
|
|
rt.t_return();
|
|
};
|
|
}
|
|
|
|
pub fn yield_thread() {
|
|
unsafe {
|
|
let rt_ptr = RUNTIME as *mut Runtime;
|
|
(*rt_ptr).t_yield();
|
|
};
|
|
}
|
|
|
|
#[naked]
|
|
#[inline(never)]
|
|
unsafe fn switch(old: *mut ThreadContext, new: *const ThreadContext) {
|
|
asm!("
|
|
mov %rsp, 0x00($0)
|
|
mov %r15, 0x08($0)
|
|
mov %r14, 0x10($0)
|
|
mov %r13, 0x18($0)
|
|
mov %r12, 0x20($0)
|
|
mov %rbx, 0x28($0)
|
|
mov %rbp, 0x30($0)
|
|
|
|
mov 0x00($1), %rsp
|
|
mov 0x08($1), %r15
|
|
mov 0x10($1), %r14
|
|
mov 0x18($1), %r13
|
|
mov 0x20($1), %r12
|
|
mov 0x28($1), %rbx
|
|
mov 0x30($1), %rbp
|
|
mov 0x38($1), %rdi
|
|
ret
|
|
"
|
|
:
|
|
: "r"(old), "r"(new)
|
|
:
|
|
: "alignstack"
|
|
);
|
|
}
|
|
# #[cfg(not(windows))]
|
|
fn main() {
|
|
let mut runtime = Runtime::new();
|
|
runtime.init();
|
|
Runtime::spawn(|| {
|
|
println!("I haven't implemented a timer in this example.");
|
|
yield_thread();
|
|
println!("Finally, notice how the tasks are executed concurrently.");
|
|
});
|
|
Runtime::spawn(|| {
|
|
println!("But we can still nest tasks...");
|
|
Runtime::spawn(|| {
|
|
println!("...like this!");
|
|
})
|
|
});
|
|
runtime.run();
|
|
}
|
|
# #[cfg(windows)]
|
|
# fn main() { }
|
|
</code></pre></pre>
|
|
<p>Still hanging in there? Good. Don't get frustrated if the code above is
|
|
difficult to understand. If I hadn't written it myself I would probably feel
|
|
the same. You can always go back and read the book which explains it later.</p>
|
|
<h2><a class="header" href="#callback-based-approaches" id="callback-based-approaches">Callback based approaches</a></h2>
|
|
<p>You probably already know what we're going to talk about in the next paragraphs
|
|
from Javascript which I assume most know. </p>
|
|
<blockquote>
|
|
<p>If your exposure to Javascript callbacks has given you any sorts of PTSD earlier
|
|
in life, close your eyes now and scroll down for 2-3 seconds. You'll find a link
|
|
there that takes you to safety.</p>
|
|
</blockquote>
|
|
<p>The whole idea behind a callback based approach is to save a pointer to a set of
|
|
instructions we want to run later. We can save that pointer on the stack before
|
|
we yield control to the runtime, or in some sort of collection as we do below.</p>
|
|
<p>The basic idea of not involving threads as a primary way to achieve concurrency
|
|
is the common denominator for the rest of the approaches. Including the one
|
|
Rust uses today which we'll soon get to.</p>
|
|
<p><strong>Advantages:</strong></p>
|
|
<ul>
|
|
<li>Easy to implement in most languages</li>
|
|
<li>No context switching</li>
|
|
<li>Low memory overhead (in most cases)</li>
|
|
</ul>
|
|
<p><strong>Drawbacks:</strong></p>
|
|
<ul>
|
|
<li>Each task must save the state it needs for later, the memory usage will grow
|
|
linearly with the number of callbacks in a chain of computations.</li>
|
|
<li>Can be hard to reason about, many people already know this as as "callback hell".</li>
|
|
<li>It's a very different way of writing a program, and will require a substantial
|
|
rewrite to go from a "normal" program flow to one that uses a "callback based" flow.</li>
|
|
<li>Sharing state between tasks is a hard problem in Rust using this approach due
|
|
to it's ownership model.</li>
|
|
</ul>
|
|
<p>An extremely simplified example of a how a callback based approach could look
|
|
like is:</p>
|
|
<pre><pre class="playpen"><code class="language-rust">fn program_main() {
|
|
println!("So we start the program here!");
|
|
set_timeout(200, || {
|
|
println!("We create tasks with a callback that runs once the task finished!");
|
|
});
|
|
set_timeout(100, || {
|
|
println!("We can even chain sub-tasks...");
|
|
set_timeout(50, || {
|
|
println!("...like this!");
|
|
})
|
|
});
|
|
println!("While our tasks are executing we can do other stuff instead of waiting.");
|
|
}
|
|
|
|
fn main() {
|
|
RT.with(|rt| rt.run(program_main));
|
|
}
|
|
|
|
use std::sync::mpsc::{channel, Receiver, Sender};
|
|
use std::{cell::RefCell, collections::HashMap, thread};
|
|
|
|
thread_local! {
|
|
static RT: Runtime = Runtime::new();
|
|
}
|
|
|
|
struct Runtime {
|
|
callbacks: RefCell<HashMap<usize, Box<dyn FnOnce() -> ()>>>,
|
|
next_id: RefCell<usize>,
|
|
evt_sender: Sender<usize>,
|
|
evt_reciever: Receiver<usize>,
|
|
}
|
|
|
|
fn set_timeout(ms: u64, cb: impl FnOnce() + 'static) {
|
|
RT.with(|rt| {
|
|
let id = *rt.next_id.borrow();
|
|
*rt.next_id.borrow_mut() += 1;
|
|
rt.callbacks.borrow_mut().insert(id, Box::new(cb));
|
|
let evt_sender = rt.evt_sender.clone();
|
|
thread::spawn(move || {
|
|
thread::sleep(std::time::Duration::from_millis(ms));
|
|
evt_sender.send(id).unwrap();
|
|
});
|
|
});
|
|
}
|
|
|
|
impl Runtime {
|
|
fn new() -> Self {
|
|
let (evt_sender, evt_reciever) = channel();
|
|
Runtime {
|
|
callbacks: RefCell::new(HashMap::new()),
|
|
next_id: RefCell::new(1),
|
|
evt_sender,
|
|
evt_reciever,
|
|
}
|
|
}
|
|
|
|
fn run(&self, program: fn()) {
|
|
program();
|
|
for evt_id in &self.evt_reciever {
|
|
let cb = self.callbacks.borrow_mut().remove(&evt_id).unwrap();
|
|
cb();
|
|
if self.callbacks.borrow().is_empty() {
|
|
break;
|
|
}
|
|
}
|
|
}
|
|
}
|
|
</code></pre></pre>
|
|
<p>We're keeping this super simple, and you might wonder what's the difference
|
|
between this approach and the one using OS threads an passing in the callbacks
|
|
to the OS threads directly. </p>
|
|
<p>The difference is that the callbacks are run on the
|
|
same thread using this example. The OS threads we create are basically just used
|
|
as timers.</p>
|
|
<h2><a class="header" href="#from-callbacks-to-promises" id="from-callbacks-to-promises">From callbacks to promises</a></h2>
|
|
<p>You might start to wonder by now, when are we going to talk about Futures?</p>
|
|
<p>Well, we're getting there. You see <code>promises</code>, <code>futures</code> and other names for
|
|
deferred computations are often used interchangeably. </p>
|
|
<p>There are formal differences between them but we'll not cover that here but it's
|
|
worth explaining <code>promises</code> a bit since they're widely known due to being used
|
|
in Javascript and have a lot in common with Rusts Futures.</p>
|
|
<p>First of all, many languages has a concept of promises but I'll use the ones
|
|
from Javascript in the examples below.</p>
|
|
<p>Promises is one way to deal with the complexity which comes with a callback
|
|
based approach.</p>
|
|
<p>Instead of:</p>
|
|
<pre><code class="language-js ignore">setTimer(200, () => {
|
|
setTimer(100, () => {
|
|
setTimer(50, () => {
|
|
console.log("I'm the last one");
|
|
});
|
|
});
|
|
});
|
|
</code></pre>
|
|
<p>We can to this:</p>
|
|
<pre><code class="language-js ignore">function timer(ms) {
|
|
return new Promise((resolve) => setTimeout(resolve, ms))
|
|
}
|
|
|
|
timer(200)
|
|
.then(() => return timer(100))
|
|
.then(() => return timer(50))
|
|
.then(() => console.log("I'm the last one));
|
|
</code></pre>
|
|
<p>The change is even more substantial under the hood. You see, promises return
|
|
a state machine which can be in one of three states: <code>pending</code>, <code>fulfilled</code> or
|
|
<code>rejected</code>. </p>
|
|
<p>When we call <code>timer(200)</code> in the sample above, we get back a promise in the state <code>pending</code>.</p>
|
|
<p>Since promises are re-written as state machines they also enable an even better
|
|
syntax which allows us to write our last example like this:</p>
|
|
<pre><code class="language-js ignore">async function run() {
|
|
await timer(200);
|
|
await timer(100);
|
|
await timer(50);
|
|
console.log("I'm the last one");
|
|
}
|
|
</code></pre>
|
|
<p>You can consider the <code>run</code> function a <em>pausable</em> task consisting of several
|
|
sub-tasks. On each "await" point it yields control to the scheduler (in this
|
|
case it's the well known Javascript event loop). </p>
|
|
<p>Once one of the sub-tasks changes state to either <code>fulfilled</code> or <code>rejected</code> the
|
|
task is scheduled to continue to the next step.</p>
|
|
<p>Syntactically, Rusts Futures 1.0 was a lot like the promises example above and
|
|
Rusts Futures 3.0 is a lot like async/await in our last example.</p>
|
|
<p>Now this is also where the similarities with Rusts Futures stop. The reason we
|
|
go through all this is to get an introduction and get into the right mindset for
|
|
exploring Rusts Futures.</p>
|
|
<blockquote>
|
|
<p>To avoid confusion later on: There is one difference you should know. Javascript
|
|
promises are <em>eagerly</em> evaluated. That means that once it's created, it starts
|
|
running a task. Rusts Futures on the other hand is <em>lazily</em> evaluated. They
|
|
need to be polled once before they do any work.</p>
|
|
</blockquote>
|
|
<br />
|
|
<div style="text-align: center; padding-top: 2em;">
|
|
<a href="/1_futures_in_rust.html" style="background: red; color: white; padding:2em 2em 2em 2em; font-size: 1.2em;"><strong>PANIC BUTTON (next chapter)</strong></a>
|
|
</div>
|
|
</main>
|
|
|
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|
<!-- Mobile navigation buttons -->
|
|
|
|
<a rel="prev" href="introduction.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|
<i class="fa fa-angle-left"></i>
|
|
</a>
|
|
|
|
|
|
|
|
<a rel="next" href="1_futures_in_rust.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|
<i class="fa fa-angle-right"></i>
|
|
</a>
|
|
|
|
|
|
<div style="clear: both"></div>
|
|
</nav>
|
|
</div>
|
|
</div>
|
|
|
|
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
|
|
|
<a href="introduction.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|
<i class="fa fa-angle-left"></i>
|
|
</a>
|
|
|
|
|
|
|
|
<a href="1_futures_in_rust.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|
<i class="fa fa-angle-right"></i>
|
|
</a>
|
|
|
|
</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>
|
|
|
|
|
|
|
|
<!-- Google Analytics Tag -->
|
|
<script type="text/javascript">
|
|
var localAddrs = ["localhost", "127.0.0.1", ""];
|
|
|
|
// make sure we don't activate google analytics if the developer is
|
|
// inspecting the book locally...
|
|
if (localAddrs.indexOf(document.location.hostname) === -1) {
|
|
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
|
|
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
|
|
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
|
|
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');
|
|
|
|
ga('create', 'UA-157536992-1', 'auto');
|
|
ga('send', 'pageview');
|
|
}
|
|
</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 -->
|
|
|
|
|
|
|
|
|
|
</body>
|
|
</html>
|