Coroutines, Self-Referential Structs, and Pinning 226 The last part is when we've reached Wait2 and our future returns Poll State::Ready : State0::Wait2(ref mut f2) => { match f2. poll(waker) { Poll State::Ready(txt) => { // Restore stack let buffer = self. stack. buffer. as_ref(). take(). unwrap(); let writer = unsafe { &mut *self. stack. writer. take(). unwrap() }; //----Code you actually wrote---- writeln!(writer, «{txt}»). unwrap(); println!("{}", buffer); //--------------------------------- self. state = State0::Resolved; // Save stack / free resources let _ = self. stack. buffer. take(); break Poll State::Ready(String::new()); } Poll State::Not Ready => break Poll State::Not Ready, } } In this segment, we restore both variables since we write the last response through our writer variable, and then print everything that's stored in our buffer to the terminal. I want to point out that the println!("{}", buffer); line takes a reference in the original coroutine/wait example, even though it might look like we pass in an owned String. Therefore, it makes sense that we restore the buffer to a &String type, and not the owned version. Transferring ownership would also invalidate the pointer in our writer variable. The last thing we do is drop the data we don't need anymore. Our self. stack. writer field is already set to None since we took ownership over it when we restored the stack at the start, but we need to take ownership over the String type that self. stack. buffer holds as well so that it gets dropped at the end of this scope too. If we didn't do that, we would hold on to the memory that's been allocated to our String until the entire coroutine is dropped (which could be much later). Now, we've made all our changes. If the rewrites we did previously were implemented in corofy, our coroutine/wait implementation could, in theory, support much more complex use cases.