async-book | Asynchronous Programming in Rust | Reactive Programming library

When you specify 'a as a generic parameter, you mean "I premit the caller to choose any lifetime it wants". The caller may as well choose 'static, for example. Then you promise to pass &'a mut i32, that is, &'static mut i32. But i does not live for 'static! That's the reason for the first error.

The second error is because you're promising you're borrowing i mutably for 'a. But again, 'a may as well cover the entire function, even after you discarded the result! The caller may choose 'static, for example, then store the reference in a global variable. If you use i after, you use it while it is mutably borrowed. BOOM!

What you want is not to let the caller choose the lifetime, but instead to say "I'm passing you a reference with some lifetime 'a, and I want you to give me back a future with the same lifetime". What we use to achieve the effect of "I'm giving you some lifetime, but let me choose which" is called HRTB (Higher-Kinded Trait Bounds).

If you only wanted to return a specific type, not a generic type, it would look like:

await does not block the current thread. It yields to another coroutine on the same thread. thread::sleep does block the current thread, which is why you should never use it in async code. Instead, you'd use something like tokio::time::sleep, which is async and yields. As the book says:

Whereas calling a blocking function in a synchronous method would block the whole thread, blocked Futures will yield control of the thread, allowing other Futures to run.

That said, if you need to wait 1 second for your test to pass, you may need to rethink the order of operations in your close. That may be indicating a race condition. I'm not familiar with which crate you're using here to know if this is expected for a unit test.

This looks like a mistake on the side of crates_io_api. Getting the next element of a Stream requires that the Stream is Unpin:

I found [...] but it is for a function that does not use async.

Yes it does. You should take a closer look at code. The original function is definitely async:

I've solved Question 3 with a lot of if statements. I hope there are some more elegant implementations. And, I really appreciate any learning material as stated in Question 1.

here's the full code that compiles (simplified):

You are passing the same Context (and thus Waker) to the poll() method of the Future returned by new_inner_task, which passes it down the chain to the poll() of the Future returned by UnboundedReceiverStream::next(). The implementation of that arranges to call wake() on this Waker at the appropriate time (when new elements appear in the channel). When that is done, Tokio polls the top-level future associated with this Waker - the join!() of the three futures.

If you omitted the line that polls the inner task and just returned Poll::Pending instead, you would get the expected situation, where your Future would be polled once and then "hang" forever, as nothing would wake it again.

When you use .await in an async function, the compiler builds a state machine behind the scenes. Each .await introduces a new state (while it waits for something) and the code in between are state transitions (aka tasks), which will be triggered based on some external event (e.g. from IO or a timer etc).

Each task gets scheduled to be executed by the async runtime, which could choose to use a different thread from the previous task. If the state transition is not safe to be sent between threads then the resulting Future is also not Send so that you get a compilation error if you try to execute it in a multi-threaded runtime.

It is completely OK for a Future not to be Send, it just means you can only execute it in a single-threaded runtime.

Perhaps someone could shed some light on this with an example of why having a non-Send type in a Future is ok, but holding it across an await is not?

Consider the following simple example:

According to justinas the answer is:

Your problem can be reduced to this: