A new chapter on Async Rust

[rbehjati]

We'd like to cover Async Rust in the course materials, possibly as an alternative to the Android part. Here is the tracking issue for adding a chapter on Async Rust: #181

Let's use this space to discuss some ideas for the content:

• What is a good running example?
• What is a good exercise?
• Any libraries to cover? (e.g., tokio)

[sakex]

- What is a good running example?

I think it should be highlighted in the context of IO-heavy tasks like HTTP requests or database transactions. In practice, I think it's mostly used for web servers (like actix-web, but it is probably out of scope.) Async data streams are also important.

-  What is a good exercise?

It would be nice to illustrate concepts around future control flow. For instance, doing a bunch of operations in parallel with join_all!, iterating over multiple async streams with tokio::select! {}. I have an idea for an exercise but it might be too complex. I will add it to the next comment.

-  Any libraries to cover? 

Tokio definitely, Reqwest is a pretty simple http request library. Flume channels are nice. Async trait is an unfortunate necessity.

[sakex]

Idea for an exercise:

We could provide some code written in a synchronous/sequential way. It would iteratively fetch a lot of images from an API we would provide, do some expensive processing on top of the images (something like applying a filter), then it would add the output to a zip archive ZIP crate. Once this is done, save the zip file to disk.

This code would be very slow and the exercise would be to rewrite this using async/await.

The challenge would be to manage tasks efficiently. The number of images would have to be high, so the processing part would block the executor and make the pending requests time out if simply relying on futures::join_all!. That would force the implementer to batch tasks (easy way, less efficient).

The ideal implementation would use tokio::task::spawn_blocking to spawn a bunch of CPU worker threads that would listen to flume multi consumer channels. Requests output would be written to those channels. A final task, listening to an MPSC channel would be used to write to the ZIP archive.

[sakex]

This is pseudo rust

So we would go from

for image_name in images {
    let image = fetch_image(image_name).await; // <- not exploiting parrallelism
    let output = process_image(image); // <- expensive CPU blocking task
    zip_archive.write(output);
}
zip_archive.save();

to

async fn fetch_and_forward_image(image_name: &str, mut output: Sender<Image>) -> Result<()> {
    let image = fetch_image(image_name).await?;
    output.send(image).await?;
}

fn process_image_worker(mut input: Receiver<Image>, mut output: Sender<Output>) {
    while let Some(img) = input.rcv() {
        let processed = process_image(img);
        output.send(processed);
    }
}

async fn zip_worker(input: Receiver<Output>) {
     let mut archive = Zip::new();
     while let Some(output) = input.rcv().await {
         // Bonus points for keeping order
         archive.write(output);
     }
     archive.save();
}

#[tokio::main]
async fn main() {
    let (img_sdr, img_rcv) = flume::mpmc::unbounded();
    let (output_sdr, output_rcv) = flume::mpsc::unbounded();
    let fetch_images_futures = images.into_iter.map(|image_name| fetch_and_forward_image(image_name, img_sdr.clone()));
    let workers = (0..workers).into_iter().map(|_| {
        tokio::spawn_blocking(
      move {
            process_image_worker(img_rcv.clone(), output_sdr.clone());
        }
       ));
      let zip_task = zip_worker(output_rcv);
      // Bonus point for handling ctrl+c and timeout
     // We need to drop channels img_sdr here
     futures::join!(fetch_images_futures, workers, zip_task);
    
    }
   

}

[mgeisler]

Just a word of warning: it's really hard for people to quickly context switch into new areas. I see that with the Multi-threaded Link Checker exercise. I figured that could be done in ~45 minutes, but I practice, I see few people who are able to complete it in that time. People have all sorts of false starts where they spend 5-10 minutes trying to do something only to scrap it. That quickly eats into the effective time people have to solve the exercise.

So in other words, I think it could be good to make an exercise where "solving it" is trivial. The emphasis would then be on actually typing out the lines of the solution. If that makes sense?

[RobinSweatman1Dg]

Including Async Rust in the course materials would be a great addition! Here are some ideas for the content:

For a running example, a simple web server could be used to demonstrate how async Rust works. The example could include handling incoming HTTP requests and returning responses.

For an exercise, students could be tasked with converting a synchronous function into an asynchronous one using async/await and futures.

Libraries like Tokio, async-std, and futures could be covered to show how they are used in async Rust programming. Students could learn how to use these libraries to perform I/O operations and manage concurrency.

Overall, incorporating Async Rust into the course materials would provide students with a valuable skillset and a deeper understanding of Rust programming.