Writing an OS in Rust: Async / Await, Hacker News

The main advantage of preemptive multitasking is that the operating system can fully control the allowed execution time of a task. This way, it can guarantee that each task gets a fair share of the CPU time, without the need to trust the tasks to cooperate. This is especially important when running third-party tasks or when multiple users share a system. The disadvantage of preemption is that each task requires its own stack. Compared to a shared stack, this results in a higher memory usage per task and often limits the number of tasks in the system. Another disadvantage is that the operating system always has to save the complete CPU register state on each task switch, even if the task only used a small subset of the registers. Preemptive multitasking and threads are fundamental components of an operating system because they make it possible to run untrusted userspace programs. We will discuss these concepts in full detail in future posts. For this post, however, we will focus on cooperative multitasking, which also provides useful capabilities for our kernel.

🔗 Cooperative Multitasking Instead of forcibly pausing running tasks at arbitrary points in time, cooperative multitasking lets each task run until it voluntarily gives up control of the CPU. This allows tasks to pause themselves at convenient points in time, for example when it needs to wait for an I / O operation anyway. Cooperative multitasking is often used at the language level, for example in form of (coroutines) or async / await . The idea is that either the programmer or the compiler inserts yield [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] operations into the program, which give up control of the CPU and allow other tasks to run. For example, a yield could be inserted after each iteration of a complex loop. It is common to combine cooperative multitasking with asynchronous operations . Instead of waiting until an operation is finished and preventing other tasks to run in this time, asynchronous operations return a "not ready" status if the operation is not finished yet. In this case, the waiting task can execute a yield operation to let other tasks run. State Since tasks define their pause points themselves, they don't need the operating system to save their state. Instead, they can save exactly the state they need for continuation before they pause themselves, which often results in better performance. For example, a task that just finished a complex computation might only need to backup the final result of the computation since it does not need the intermediate results anymore. Language-supported implementations of cooperative tasks are often even able to backup up the required parts of the call stack before pausing. As an example, Rust's async / await implementation stores all local variables that are still needed in an automatically generated struct (see below). By backing up the relevant parts of the call stack before pausing, all tasks can share a single call stack, which results in a much smaller memory consumption per task. This makes it possible to create an almost arbitrary number of cooperative tasks without running out of memory. (🔗) Discussion The drawback of cooperative multitasking is that an uncooperative task can potentially run for an unlimited amount of time. Thus, a malicious or buggy task can prevent other tasks from running and slow down or even block the whole system. For this reason, cooperative multitasking should only be used when all tasks are known to cooperate. As a counterexample, it's not a good idea to make the operating system rely on the cooperation of arbitrary userlevel programs. However, the strong performance and memory benefits of cooperative multitasking make it a good approach for usage within

a program, especially in combination with asynchronous operations. Since an operating system kernel is a performance-critical program that interacts with asynchronous hardware, cooperative multitasking seems like a good approach for implementing concurrency. (🔗) Async / Await in Rust

The Rust language provides first-class support for cooperative multitasking in form of async / await. Before we can explore what async / await is and how it works, we need to understand how futures and asynchronous programming work in Rust.

🔗 (Futures) A future

represents a value that might not be available yet. This could be for example an integer that is computed by another task or a file that is downloaded from the network. Instead of waiting until the value is available, futures make it possible to continue execution until the value is needed. (🔗

(Example) The concept of futures is best illustrated with a small example: This sequence diagram shows a main function that reads a file from the file system and then calls a function foo This process is repeated two times: Once with a synchronous read_file call and once with an asynchronous async_read_file call. With the synchronous call, the main function needs to wait until the file is loaded from the file system. Only then it can call the foo function, which requires it to again wait for the result. With the asynchronous async_read_file call, the file system directly returns a future and loads the file asynchronously in the background. This allows the main ) function to call foo much earlier , which then runs in parallel with the file load. In this example, the file load even finishes before foo returns, so main can directly work with the file without further waiting after foo returns. [E0594] [dependencies.crossbeam-queue] (Futures in Rust In Rust, futures are represented by the Future (trait, which looks like this: pub trait (Future {      (type) (Output) (Output) ;      (fn) (poll) self: Pin & mut Self >, cx: & mut Context) -> Poll (Self ::) Output>; } The (associated type) Output specifies the type of the asynchronous value. For example, the async_read_file function in the diagram above would return a Future instance with Output set to File . The poll method allows to check if the value is already available. It returns a Poll enum, which looks like this: pub enum (Poll) {     Ready (T),     Pending, } When the value is already available (eg the file was fully read from disk), it is returned wrapped in the Ready variant. Otherwise, the Pending variant is returned, which signals the caller that the value is not yet available. The poll method takes two arguments: : self: Pin and cx: & mut Context The former behaves like a normal & mut self reference, with the difference that the Self (value is) pinned [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] to its memory location. Understanding Pin and why it is needed is difficult without understanding how async / await works first. We will therefore explain it later in this post. The purpose of the cx: & mut Context parameter is to pass a Waker instance to the asynchronous task, eg the file system load. This Waker allows the asynchronous task to signal that it (or a part of it) is finished, eg that the file was loaded from disk. Since the main task knows that it will be notified when the Future is ready, it does not need to call poll over and over again. We will explain this process in more detail later in this post when we implement our own waker type. (🔗) (Working with Futures) We now know how futures are defined and understand the basic idea behind the

poll method. However, we still don't know how to effectively work with futures. The problem is that futures represent results of asynchronous tasks, which migh t be not available yet. In practice, however, we often need these values ​​directly for further calculations. So the question is: How can we efficiently retrieve the value of a future when we need it? ing Waiting on Futures One possible answer is to wait until a future becomes ready. This could look something like this: let (future) = (async_read_file)

"foo.txt" [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] ; (let) (file_content =loop

{      (match) future.poll (...) {         Poll :: Ready (value)

=> break

value,         Poll :: Pending ==

{}, // do nothing      } } Here we actively (wait for the future by calling (poll over and over again in a loop. The arguments to poll don 't matter here, so we omitted them. While this solution works, it is very inefficient because we keep the CPU busy until the value becomes available. A more efficient approach could be to block the current thread until the future becomes available. This is of course only possible if you have threads, so this solution does not work for our kernel, at least not yet. Even on systems where blocking is supported, it is often not desired because it turns an asynchronous task into a synchronous task again, thus inhibiting the potential performance benefits of parallel tasks. (🔗) Future Combinators An alternative to waiting is to use future combinators. Future combinators are methods like map that allow chaining and combining futures together, similar to the methods on (Iterator) . Instead of waiting on the future, these combinators return a future themselves, which applies the mapping operation on poll . As an example, a simple string_len (combinator for converting a) (Future) to a [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] (Future) could look like this: struct (StringLen) {     inner_future: F, } (impl) (Future) [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] (for (StringLen) (where (F: Future) {      (type) (Output) (Output)=usize

;      (fn) (poll) (mut)

self: Pin & mut Self

>, cx:

& mut (Context>) -> Poll

 {          (match)   self.inner_future.poll (cx) {             Poll :: Ready (s)  
=>   Poll :: Ready (s.len ()),             Poll :: Pending ==
 Poll :: Pending,         }     } }   (fn)   (string_len) string: impl Future )     -> impl Future 
  (usize)  
> {     StringLen {         inner_future: string,     } }    // Usage  (fn)   (file_len () -> impl Future 
  usize  > {      (let)   (file_content_future == async_read_file (  “foo.txt”  
);     string_len (file_content_future) }   This code does not quite work because it does not handle  (pinning) [dependencies.conquer-once] , but it suffices as an example. The basic idea is that the  string_len  function wraps a given  Future  instance into a new  StringLen   struct, which also implements  Future . When the wrapped future is polled, it polls the inner future. If the value is not ready yet,  Poll :: Pending  is returned from the wrapped future too. If the value is ready, the string is extracted from the  Poll :: Ready  variant and its length is calculated. Afterwards, it is wrapped in  Poll :: Ready  again and returned.   with this  string_len  function, we can calculate the length of an asynchronous string without waiting for it. Since the function returns a  Future  again, the caller can't work directly on the returned value, but needs to use combinator functions again. This way, the whole call graph becomes asynchronous and we can efficiently wait for multiple futures at once at some point, e.g. in the main function.   Manually writing combinator functions is difficult, therefore they are often provided by libraries. While the Rust standard library itself provides no combinator methods yet, the semi-official (and  no_std  (compatible)   futures   crate does. Its  FutureExt  trait provides high-level combinator methods such as   map  (or  or 
 then  [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)], which can be used to manipulate the result with arbitrary closures.   (🔗)  Advantages   The big advantage of future combinators is that they keep the operations asynchronous. In combination with asynchronous I / O interfaces, this approach can lead to very high performance. The fact that future combinators are implemented as normal structs with trait implementations allows the compiler to excessively optimize them. For more details, see the  (Zero-cost futures in Rust   post, which announced the addition of futures to the Rust ecosystem.   
 🔗  Drawbacks   While future combinators make it possible to write very efficient code, they can be difficult to use in some situations because of the type system and the closure based interface . For example, consider code like this:   fn  (example) min_len:  
 usize    -> impl Future  {     async_read_file (  “foo.txt”  ). then ( move |  (content   
 {          (if)   (content.len ()   ( min_len {             Either :: Left (async_read_file ( 
 “bar.txt”   map (| s | content   (  &  s))         }   (else)  
 {             Either :: Right (future :: ready (content))         }     }) }   ( try it on the playground  
   Here we read the file  foo.txt  and then use the  (then   combinator to chain a second future based on the file content. If the content length is smaller than the given  min_len , we read a different  bar.txt  file and append it to  content  using the   map    combinator. Otherwise we return only the content of  foo.txt .   We need to use the 
  move  keyword  for the closure passed to  then  because otherwise there would be a lifetime error for  min_len  The reason for the   Either   wrapper is that if and else blocks must always have the same type. Since we return different future types in the blocks, we must use the wrapper type to unify them into a single type. The   ready   function wraps a value into a future, which is immediately ready. The function is required here because the  Either  wrapper expects that the wrapped value implements  Future .   As you can imagine, this can quickly lead to very complex code for larger projects. It gets especially complicated if borrowing and different lifetimes are involved. For this reason, a lot of work was invested to add support for async / await to Rust, with the goal of making asynchronous code radically simpler to write.   (🔗) (The Async / Await Pattern)   The idea behind async / await is to let the programmer write code that  looks  like normal synchronous code, but is turned into asynchronous code by the compiler. It works based on the two keywords  async  and  await  . The  async  keyword can be used in a function signature to turn a synchronous function into an asynchronous function that returns a future:   async  (fn)   (foo () ->  
 (u)  {       0  }    // the above is roughly translated by the compiler to:  (fn)   (foo () -> impl Future 
  (u)> {     future :: ready (  (0)  
) }   This keyword alone wouldn't be that useful. However, inside  async  functions , the  await  keyword can be used to retrieve the asynchronous value of a future:   async  (fn)   example (min_len:   (usize)  
) -> String {      (let)   (content == async_read_file (  “foo.txt”  
). await;      (if)   (content.len ()   ( min_len {         content     &   async_read_file (  “bar.txt”  [dependencies.conquer-once]  await     }   (else)  
 {         content     } }   (  Try it on the playground )   This function is a direct translation of the  example  function that used combinator functions from  above . Using the . Await  operator , we can retrieve the value of a future without needing any closures or  Either 
 types. As a result, we can write our code like we write normal synchronous code, with the difference that  this is still asynchronous code . (🔗) (State Machine Transformation)  What the compiler does behind this scenes is to transform the body of the  async  function into a   state machine  [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)], with each [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] . await  call representing a different state. For the above  example  function , the compiler creates a state machine with the following four states:      
 Each state represents a different pause point of the function. The  “Start”  and  "End" 

	

			
	

			

		
	
		




 states represent the function at the beginning and end of its execution. The  "Waiting on foo.txt"  represents that the function is currently waiting for the first  async_read_file 
  result. Similarly, the  “Waiting on bar.txt”  state represents the pause point where the function is waiting on the second  async_read_file  result.   The state machine implements the  Future  (trait by making each ) (poll  call a possible state transition:       The diagram uses arrows to represent state switches and diamond shapes to represent alternative ways. For example, if the  foo.txt 
  file is not ready, the path marked with  “no”  is taken and the  “Waiting on foo.txt”  state is reached. Otherwise, the  “yes”  path is taken . The small red diamond without caption represents the  if content.len ()  (example) (function.)   We see that the first  poll  call starts the function and lets it run until it reaches a future that is not ready yet. If all futures on the path are ready, the function can run till the  “End”  state, where it returns its result wrapped in  Poll :: Ready . Otherwise, the state machine enters a waiting state and returns  Poll :: Pending . On the next  poll  call , the state machine then starts from the last waiting state and retries the last operation.   🔗  (Saving State)  In order to be able to continue from the last waiting state, the state machine must keep track of the current state internally. In addition, it must save all the variables that it needs to continue execution on the next  poll  call. This is where the compiler can really shine: Since it knows which variables are used when, it can automatically generate structs with exactly the variables that are needed.   As an example, the compiler generates structs like the following for the above  example  function:    / / The `example` function again so that you don't have to scroll up  (async)   (fn   (example) min_len:  
 usize  
  -> String {      (let)   (content == async_read_file (  “foo.txt”  
). await;      (if)   (content.len ()   ( min_len {         content     &   async_read_file (  “bar.txt”  
). await     }   (else)  
 {         content     } }    // The compiler-generated state structs:   (struct)   StartState {     min_len:   (usize)  , }   (struct)   WaitingOnFooTxtState {     min_len:   (usize)  ,     foo_txt_future: impl Future , }   (struct)   WaitingOnBarTxtState {     content: String,     bar_txt_future: impl Future , }   (struct)   EndState {}   In the "start" and  "Waiting on foo. txt " states, the  min_len  parameter needs to be stored because it is required for the comparison with  content.len ()  later. The  "Waiting on foo.txt"  additionally stores a  foo_txt_future , which represents the future returned by the  async_read_file  call. This future needs to be polled again when the state machine continues, so it needs to be saved.   The  “Waiting on bar.txt”  (state contains the  content  variable because it is needed for the string concatenation after  bar .txt  is ready. It also stores a  bar_txt_future  that represents the in-progress load of  bar.txt 
 . The struct does not contain the  min_len  variable because it is no longer needed after the  content.len ()  comparison. In the  "end"  state, no variables are stored because the function did already run to completion.   Keep in mind that this is only an example for the code that the compiler could generate. The struct names and the field layout are an implementation detail and might be different.   [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] (The Full State Machine Type)   While the exact compiler-generated code is an implementation detail, it helps in understanding to imagine how the generated state machine  could  look for the  example  function. We already defined the structs representing the different states and containing the required variables. To create a state machine on top of them, we can combine them into an 
  enum :   enum  ExampleStateMachine {     Start (StartState),     WaitingOnFooTxt (WaitingOnFooTxtState),     WaitingOnBarTxt (WaitingOnBarTxtState),     End (EndState), }   We define a separate enum variant for each state and add the corresponding state struct to each variant as a field. To implement the state transitions, the compiler generates an implementation of the  Future  trait based on the  example  function:   impl  (Future)   (for   ExampleStateMachine {      (type)   (Output) (Output)== String;   // return type of `example`       (fn)   (poll) self: Pin   & mut Self  >, cx:   & mut   Context) -> Poll   (Self ::) (Output> {          (loop)   {              (match)   (self {  // TODO: handle pinning                  ExampleStateMachine :: Start (state)  =>  {…}                 ExampleStateMachine :: WaitingOnFooTxt (state)  
=>   {…}                 ExampleStateMachine :: WaitingOnBarTxt (state)  
=>   {…}                 ExampleStateMachine :: End (state)  
=>   {…}             }         }     } }   The  The Output  (type of the future is  String  because it's the the return type of the  example  function. To implement the  poll  function , we use a match statement on the current state inside a  loop . The idea is that we switch to the next state as long as possible and use an explicit  return Poll :: Pending  when we can't continue.   For simplicity, we only show simplified code and don't handle  pinning , ownership, lifetimes, etc. So this and the following code should be treated as pseudo-code and not used directly. Of course, the real compiler-generated code handles everything correctly, albeit possibly in a different way.   To keep the code excerpts small, we present the code for each match arm separately. Let's begin with the  Start  state:   ExampleStateMachine :: Start (state)  =>  
 {       // from body of `example`      (let)   (foo_txt_future == async_read_file (  “foo.txt”  
);       // `.await` operation      (let)   (state == WaitingOnFooTxtState {         min_len: state.min_len,         foo_txt_future,     };      [1, 2, 3]   (self) (self)== ExampleStateMachine :: WaitingOnFooTxt (state); }   The state machine is in the  Start  state when it is right at the beginning of the function. In this case, we execute all the code from the body of the  example  function until the first . await . To handle the . Await  operation, we change the state of the  self  state machine to  WaitingOnFooTxt , which includes the construction of the  WaitingOnFooTxtState 
  struct.   Since the  match self {…}  statement is executed in a loop, the execution jumps to the  WaitingOnFooTxt  arm next:   ExampleStateMachine :: WaitingOnFooTxt (state)  =>  
 {      (match)   state.foo_txt_future.poll (cx) {         Poll :: Pending ==return   Poll :: Pending,         Poll :: Ready (content) =>   {               // from body of `example`              (if)   (content.len ()   ( state.min_len {                  (let)   (bar_txt_future == async_read_file (  “bar.txt”  
);                   // `.await` operation                  (let)   (state == WaitingOnBarTxtState {                     content,                     bar_txt_future,                 };                  [1, 2, 3]   (self) (self)== ExampleStateMachine :: WaitingOnBarTxt (state);             }   (else)  
 {                  [1, 2, 3]   (self) (self)== ExampleStateMachine :: End (EndState));                  (return)   Poll :: Ready (content);             }         }     } }   In this match arm we first call the  poll  function of the  foo_txt_future . If it is not ready, we exit the loop and return  Poll :: Pending [dependencies.futures-util] . Since  self  stays in the  WaitingOnFooTxt  state in this case , the next  poll  call on the state machine will enter the same match arm and retry polling the  foo_txt_future .  When the  foo_txt_future  (is ready, we assign the result to the   variable and continue to execute the code of the  example  function: If  content.len ()  is smaller than the  min_len  saved in the state struct, the  bar.txt  file is read asynchronously. We again translate the . Await  (operation into a state change, this time into the  WaitingOnBarTxt   state. Since we're executing the  match   inside a loop, the execution directly jumps to the match arm for the new state afterwards, where the  bar_txt_future  is polled.   In case we enter the  else  branch, no further . await  operation occurs. We reach the end of the function and return  content  wrapped in  Poll :: Ready . We also change the current state to the  End  state.   The code for the  WaitingOnBarTxt  state looks like this:   ExampleStateMachine :: WaitingOnBarTxt (state)  =>  
 {      (match)   state.bar_txt_future.poll (cx) {         Poll :: Pending ==return   Poll :: Pending,         Poll :: Ready (bar_txt) =>   {              [1, 2, 3]   (self) (self)== ExampleStateMachine :: End (EndState));               // from body of `example`              (return)   (Poll :: Ready (state.content) [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]   &   bar_txt);         }     } }   Similar to the  WaitingOnFooTxt  state, we start by polling the  bar_txt_future . If it is still pending, we exit the loop and return  Poll :: Pending [dependencies.futures-util] . Otherwise, we can perform the last operation of the  example  function: Concatenating the  content  variable with the result from the future. We update the state machine to the  End  state and then return the result wrapped in  Poll :: Ready .  Finally, the code for the  End  state looks like this:   ExampleStateMachine :: End (  (_)  ) =>  
 {     panic! (  “poll called after Poll :: Ready was returned”  ; }   Futures should not be polled again after they returned  Poll :: Ready , therefore we panic if  poll  is called when we are already in the  End  state.   We now know how the compiler-generated state machine and its implementation of the  Future  trait  ) (could  look like. In practice, the compiler generates code in different way. (In case you're interested, the implementation is currently based on 
  generators   , but this is only an implementation detail.)   The last piece of the puzzle is the generated code for the  example  function itself. Remember, the function header was defined like this:   async  (fn)   example (min_len:   (usize)  
) -> String   Since the complete function body is now implemented by the state machine, the only thing that the function needs to do is to initialize the state machine and return it . The generated code for this could look like this:   fn  (example) min_len:  
 usize    -> ExampleStateMachine {     ExampleStateMachine :: Start (StartState {         min_len,     }) }   The function no longer has an  async  modifier since it now explicitly returns a  ExampleStateMachine  type, which implements the  (Future ) trait. As expected, the state machine is constructed in the  Start  state and the corresponding state struct is initialized with the  min_len  parameter.   Note that this function does not start the execution of the state machine. This is a fundamental design decision of futures in Rust: They do nothing until they are polled for the first time.   (🔗) Pinning  We already stumbled across  pinning  multiple times in this post. Now is finally the time to explore what pinning is and why it is needed.   ()  
 Self-Referential Structs   As explained above, the state machine transformation stores the local variables of each pause point in a struct. For small examples like our  example  function, this was straightforward and did not lead to any problems. However, things become more difficult when variables reference each other. For example, consider this function:   async  (fn)   (pin_example () ->   (i)  {      (let)   array == [1, 2, 3];      (let)   (element) =&  
 array [2];     async_write_file (  “foo.txt”  , element.to_string ()). await;      [1, 2, 3]   element }   This function creates a small  array  (with the contents  (1) ,  (2) , and  3) . It then creates a reference to the last array element and stores it in an  element  variable. Next, it asynchronously writes the number converted to a string to a  foo.txt  file. Finally, it returns the number referenced by  element .   Since the function uses a single  await  operation, the resulting state machine has three states: start, end, and "waiting on write". The function takes no arguments, so the struct for the start state is empty. Like before, the struct for the end state is empty too because the function is finished at this point. The struct for the "waiting on write" state is more interesting:   struct  WaitingOnWriteState {     array: [1, 2, 3],     element: 0x  (a,   
 // address of the last array element  }   We need to store both the  array  and  element  variables because  element  (is required for the return value and  array) (is referenced by  element . Since  element  is a reference , it stores a  pointer  (ie a memory address) to the referenced element. We used  0x  (a)  as an example memory address here. In reality it needs to be the address of the last element of the  array  field, so it depends on where the struct lives in memory. Structs with such internal pointers are called  self-referential  structs because they reference themselves from one of their fields.    🔗  The Problem with Self-Referential Structs [dependencies.conquer-once]   The internal pointer of our self-referential struct leads to a fundamental problem, which becomes apparent when we look at its memory layout:     The  array  field starts at address 0x  and the  (element) field at address 0x . It points to address 0x  a because the last array element lives at this address. At this point, everything is still fine. However, an issue occurs when we move this struct to a different memory address:     We moved the struct a bit so that it starts at address  (0x) 
 now. This could for example happen when we pass the struct as a function argument or assign it to a different stack variable. The problem is that the  element  (field still points to address  0x  (a) even though the last  (array) element now lives at address  (0x) a  Thus, the pointer is dangling with the result that undefined behavior occurs on the next  poll  call.    (🔗) (Possible Solutions)   There are three fundamental approaches to solve the dangling pointer problem:   [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]  (Update the pointer on move:  The idea is to update the internal pointer whenever the struct is moved in memory so that it is still valid after the move. Unfortunately, this approach would require extensive changes to Rust that would result in potentially huge performance losses. The reason is that some kind of runtime would need to keep track of the type of all struct fields and check on every move operation whether a pointer update is required.    (store an offset instead of self-references: : To avoid the requirement for updating pointers, the compiler could try to store self-references as offsets from the struct's beginning instead. For example, the  element  field of the above  WaitingOnWriteState  struct could be stored in form of an  element_offset  field with value 8 because the array element that the reference points to starts 8 bytes after the struct's beginning. Since the offset stays the same when the struct is moved, no field updates are required.   The problem of this approach is that it requires the compiler to detect all self-references. This is not possible at compile-time because the value of a reference might depend on user input, so we would need a runtime system again to analyze references and correctly create the state structs. This would not only result in runtime costs, but also prevent certain compiler optimizations, so that it would cause large performance losses again.    Forbid moving the struct:  As we saw above, the dangling pointer only occurs when we move the struct in memory. By completely forbidding move operations on self-referential structs, the problem can be also avoided. The big advantage of this approach is that it can be implemented at the type system level without additional runtime costs. The drawback is that it puts the burden of dealing with move operations on possibly self-referential structs on the programmer.   (Because its principle to provide  zero cost abstractions , which means that abstractions should not impose additional runtime costs, Rust decided for the third solution. For this, the  pinning [derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)] (API  API was proposed in  RFC  . In the following, we will give a short overview of this API and explain how it works with async / await and futures.  
  🔗  Heap Values ​​  The first observation is that  (heap allocated [dependencies.futures-util]  values ​​already have a fixed memory address most of the time. They are created using a call to  allocate