From 0d0c265dc7e0e23b993a5b04478c75991af496f0 Mon Sep 17 00:00:00 2001 From: Carl Fredrik Samson Date: Sat, 4 Apr 2020 23:40:48 +0200 Subject: [PATCH] finished background information --- ...res.html => 0_background_information.html} | 198 +++++++++------ ...nformation.html => 1_futures_in_rust.html} | 10 +- book/2_waker_context.html | 6 +- book/3_generators_pin.html | 2 +- book/4_pin.html | 2 +- book/6_future_example.html | 2 +- book/8_finished_example.html | 2 +- book/conclusion.html | 2 +- book/index.html | 2 +- book/introduction.html | 6 +- book/print.html | 196 +++++++++------ book/searchindex.js | 2 +- book/searchindex.json | 2 +- ...futures.md => 0_background_information.md} | 229 +++++++++++------- ...nd_information.md => 1_futures_in_rust.md} | 2 +- src/SUMMARY.md | 4 +- 16 files changed, 399 insertions(+), 268 deletions(-) rename book/{1_why_futures.html => 0_background_information.html} (76%) rename book/{1_background_information.html => 1_futures_in_rust.html} (93%) rename src/{1_why_futures.md => 0_background_information.md} (62%) rename src/{1_background_information.md => 1_futures_in_rust.md} (98%) diff --git a/book/1_why_futures.html b/book/0_background_information.html similarity index 76% rename from book/1_why_futures.html rename to book/0_background_information.html index 3864a0f..45b4ae7 100644 --- a/book/1_why_futures.html +++ b/book/0_background_information.html @@ -3,7 +3,7 @@ - Why Futures - Futures Explained in 200 Lines of Rust + Background information - Futures Explained in 200 Lines of Rust @@ -78,7 +78,7 @@ @@ -149,14 +149,22 @@
-

Why Futures

+

Some Background Information

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.

+

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.

+
+

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.

+

Threads provided by the operating system

-

Now one way of accomplishing this is letting the OS take care of everything for +

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.

+

The runtime we use to handle concurrency for us is the operating system itself.

Advantages:

  • Simple
    • @@ -168,14 +176,14 @@ accomplish and write code like we normally would.

    • 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 soon.
      • +run out of memory pretty fast.
    • There are a lot of syscalls involved. This can be pretty costly when the number of tasks is high.
    • The OS has many things it needs to handle. It might not switch back to your thread as fast as you'd wish.
    • Might not be an option on some systems
    -

    Using OS threads in Rust looks like this:

    +

    Using OS threads in Rust looks like this:

    use std::thread;
 
 fn main() {
@@ -203,18 +211,20 @@ fn main() {
 
    OS threads sure has some pretty big advantages. So why all this talk about
 "async" and concurrency in the first place?
    
 
    First of all. For computers to be efficient it needs to multitask. Once you
-start to look under the covers (like how an operating system works) 
+start to look under the covers (like how an operating system works)
 you'll see concurrency everywhere. It's very fundamental in everything we do.
    
 
    Secondly, we have the web. 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. That's why you'll see so many async web frameworks
-and database drivers today.
    
-
    However, for a huge number of tasks, the standard OS threads will often be the
+when creating new threads. 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.
    
+
    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.
    
 
    Now, let's look at some other options for multitasking. They all have in common
-that they implement a way to do multitasking by implementing a "userland"
+that they implement a way to do multitasking by having a "userland"
 runtime:
    
 
    Green threads
    
 
    Green threads has been popularized by GO in the recent years. Green threads
@@ -255,10 +265,12 @@ platforms.
 
    If you were to implement green threads in Rust, it could look something like
 this:
    
 
    
-
    The example presented below is from an earlier book I wrote about green
-threads called Green Threads Explained in 200 lines of Rust.
+
    The example presented below is an adapted example from an earlier gitbook I
+wrote about green threads called Green Threads Explained in 200 lines of Rust.
 If you want to know what's going on you'll find everything explained in detail
-in that book.
    
+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.
    
 
    
 
    #![feature(asm)]
 #![feature(naked_functions)]
@@ -285,6 +297,7 @@ struct Thread {
     stack: Vec<u8>,
     ctx: ThreadContext,
     state: State,
+    task: Option<Box<dyn Fn()>>,
 }
 
 #[derive(Debug, Default)]
@@ -297,6 +310,7 @@ struct ThreadContext {
     r12: u64,
     rbx: u64,
     rbp: u64,
+    thread_ptr: u64,
 }
 
 impl Thread {
@@ -306,6 +320,7 @@ impl Thread {
             stack: vec![0_u8; DEFAULT_STACK_SIZE],
             ctx: ThreadContext::default(),
             state: State::Available,
+            task: None,
         }
     }
 }
@@ -317,11 +332,14 @@ impl Runtime {
             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,
@@ -358,40 +376,56 @@ impl Runtime {
                 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);
         }
-        self.threads.len() > 0
+        true
     }
 
-    pub fn spawn(&mut self, f: fn()) {
-        let available = self
-            .threads
-            .iter_mut()
-            .find(|t| t.state == State::Available)
-            .expect("no available thread.");
-        let size = available.stack.len();
+    pub fn spawn<F: Fn() + 'static>(f: F){
         unsafe {
-            let s_ptr = available.stack.as_mut_ptr().offset(size as isize);
-            let s_ptr = (s_ptr as usize & !15) as *mut u8;
-            ptr::write(s_ptr.offset(-24) as *mut u64, guard as u64);
-            ptr::write(s_ptr.offset(-32) as *mut u64, f as u64);
-            available.ctx.rsp = s_ptr.offset(-32) as u64;
+            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;
         }
-        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;
-        (*rt_ptr).t_return();
+        let rt = &mut *rt_ptr;
+        println!("THREAD {} FINISHED.", rt.threads[rt.current].id);
+        rt.t_return();
     };
 }
 
@@ -413,7 +447,7 @@ unsafe fn switch(old: *mut ThreadContext, new: *const ThreadContext) {
         mov     %r12, 0x20($0)
         mov     %rbx, 0x28($0)
         mov     %rbp, 0x30($0)
-   
+
         mov     0x00($1), %rsp
         mov     0x08($1), %r15
         mov     0x10($1), %r14
@@ -421,43 +455,45 @@ unsafe fn switch(old: *mut ThreadContext, new: *const ThreadContext) {
         mov     0x20($1), %r12
         mov     0x28($1), %rbx
         mov     0x30($1), %rbp
+        mov     0x38($1), %rdi
         ret
         "
     :
-    :"r"(old), "r"(new)
+    : "r"(old), "r"(new)
     :
-    : "volatile", "alignstack"
+    : "alignstack"
     );
 }
 
 fn main() {
     let mut runtime = Runtime::new();
     runtime.init();
-    runtime.spawn(|| {
-        println!("THREAD 1 STARTING");
-        let id = 1;
-        for i in 0..10 {
-            println!("thread: {} counter: {}", id, i);
-            yield_thread();
-        }
-        println!("THREAD 1 FINISHED");
+    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!("THREAD 2 STARTING");
-        let id = 2;
-        for i in 0..15 {
-            println!("thread: {} counter: {}", id, i);
-            yield_thread();
-        }
-        println!("THREAD 2 FINISHED");
+    Runtime::spawn(|| {
+        println!("But we can still nest tasks...");
+        Runtime::spawn(|| {
+            println!("...like this!");
+        })
     });
     runtime.run();
 }
+
 
    
-
    Callback based approach
    
-
    You probably already know this from Javascript since it's extremely common.
-The whole idea behind a callback based approach is to save a pointer to a
-set of instructions we want to run later on.
    
+
    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.
    
+
    Callback based approaches
    
+
    You probably already know what we're going to talk about in the next paragraphs
+from Javascript which I assume most know. If your exposure to Javascript 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.
    
+
    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.
    
 
    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.
    
@@ -470,8 +506,10 @@ Rust uses today which we'll soon get to.
    
 
    Drawbacks:
    
 
      
 
    • Each task must save the state it needs for later, the memory usage will grow
-linearly with the number of callbacks in a task.
      • 
+linearly with the number of callbacks in a chain of computations.
 
    • Can be hard to reason about, many people already know this as as "callback hell".
      • 
+
    • It's a very different way of writing a program, and it can be difficult to
+get an understanding of the program flow.
      • 
 
    • Sharing state between tasks is a hard problem in Rust using this approach due
 to it's ownership model.
      • 
 
    
@@ -552,22 +590,23 @@ same thread using this example. The OS threads we create are basically just used
 as timers.
    
 
    From callbacks to promises
    
 
    You might start to wonder by now, when are we going to talk about Futures?
    
-
    Well, we're getting there. You see promises, futures and deferreds are 
-often used interchangeably in day to day jargon. There are some formal
-differences between which is used which we'll not cover here but it's worth
-explaining promises a bit as a segway to Rusts Futures.
    
+
    Well, we're getting there. You see promises, futures and other names for
+deferred computations are often used interchangeably. There are formal
+differences between them but we'll not cover that here but it's worth
+explaining promises a bit since they're widely known due to beeing used in
+Javascript and will serve as segway to Rusts Futures.
    
 
    First of all, many languages has a concept of promises but I'll use the ones
-from Javascript as an example.
    
+from Javascript in the examples below.
    
 
    Promises is one way to deal with the complexity which comes with a callback
 based approach.
    
 
    Instead of:
    
 
    setTimer(200, () => {
-    setTimer(100, () => {
-        setTimer(50, () => {
-            console.log("I'm the last one");
-        })
-    })
-})
+  setTimer(100, () => {
+    setTimer(50, () => {
+      console.log("I'm the last one");
+    });
+  });
+});
 
    
 
    We can to this:
    
 
    function timer(ms) {
@@ -580,12 +619,11 @@ timer(200)
 .then(() => console.log("I'm the last one));
 
    
 
    The change is even more substantial under the hood. You see, promises return
-a state which is either pending, fulfilled or rejected. So when we call
-timer(200) in the sample above, we get back a promise in the state pending.
    
-
    A promise is a state machine which makes one step when the I/O operation
-is finished.
    
-
    This allows for an even better syntax where we now can write our last example
-like this:
    
+a state machine which can be in one of three states: pending, fulfilled or 
+rejected. So when we call timer(200) in the sample above, we get back a 
+promise in the state pending.
    
+
    Since promises are re-written as state machines they also enable an even better
+syntax where we now can write our last example like this:
    
 
    async function run() {
     await timer(200);
     await timer(100);
@@ -593,12 +631,16 @@ like this:
    
     console.log("I'm the last one");
 }
 
    
-
    Now this is also where the similarities stop. The reason we went through all
-this is to get an introduction and get into the right mindset for exploring
-Rusts Futures.
    
-
    Syntactically though, this is relevant. 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.
    
+
    You can consider the run function a pausable 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). Once one of the sub-tasks changes
+state to either fulfilled or rejected the task is sheduled to continue to
+the next step.
    
+
    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.
    
+
    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.
    
 
    
 
    To avoid confusion later on: There is one difference you should know. Javascript
 promises are eagerly evaluated. That means that once it's created, it starts
@@ -617,7 +659,7 @@ need to be polled once before they do any work. You'll see in a moment.
    
                         
 
                         
-                            
                         
@@ -635,7 +677,7 @@ need to be polled once before they do any work. You'll see in a moment.
    
                 
 
                 
-                    
                 
diff --git a/book/1_background_information.html b/book/1_futures_in_rust.html
similarity index 93%
rename from book/1_background_information.html
rename to book/1_futures_in_rust.html
index 5ff356e..ee995f2 100644
--- a/book/1_background_information.html
+++ b/book/1_futures_in_rust.html
@@ -3,7 +3,7 @@
     
         
         
-        Some background information - Futures Explained in 200 Lines of Rust
+        Futures in Rust - Futures Explained in 200 Lines of Rust
         
 
         
@@ -78,7 +78,7 @@
 
         
@@ -149,7 +149,7 @@
 
                 
    
                     
    
-                        
    Some background information
    
+                        
    Futures in Rust
    
 
    
 
    Relevant for:
    
 
      
@@ -279,7 +279,7 @@ it needs to be, so go on and read these chapters if you feel a bit unsure.