Asynchrone Programmierung

Funktionsweise von f.await

Gegeben sei ein Future f. Welche der folgenden Aussagen beschreibt am besten, wie f.await funktioniert?

1. Es ruft f.push(...) einmal auf, wodurch ein Callback ausgeführt wird, der den restlichen Code nach f.await enthält, sobald f bereit ist.

2. Es ruft f.poll() in einer Schleife auf und beendet diese, wenn f bereit ist, oder fragt sofort erneut ab, wenn f nicht bereit ist.

3. Es ruft f.poll() in einer Schleife auf und beendet diese, wenn f bereit ist, oder gibt die Kontrolle an die asynchrone Laufzeit zurück, wenn f nicht bereit ist.

4. Es ruft f.poll() einmal auf, was an Ort und Stelle blockiert, bis f bereit ist.

Prüfen

Rust verwendet ein Poll-basiertes Modell für die Ausführung von Futures. Ein await-Punkt wird in eine Schleife desugariert, die wiederholt .poll() aufruft und nach jeder erfolglosen Abfrage die Kontrolle an die asynchrone Laufzeit abgibt, um die Ausführung von anderem asynchronen Code zu ermöglichen. Die Laufzeit kann später den f.await-Code „aufwecken“, um f erneut abzufragen.

---

Pinning und undefiniertes Verhalten

Stellen Sie sich vor, Rust würde nicht verlangen, dass Futures gepinnt werden, um abgefragt zu werden. Welche der folgenden asynchronen Funktionen könnte potenziell undefiniertes Verhalten verursachen, wenn sie nicht gepinnt ist?

1. async fn example() -> i32 {
   let x = 0;
   sleep(Duration::from_secs(1)).await;
   x
   }

2. async fn example(x: &i32) -> i32 {
   sleep(Duration::from_secs(1)).await;
   *y
   }

3. async fn example(x: Vec<i32>) -> i32 {
   sleep(Duration::from_secs(1)).await;
   x[0]
   }

4. async fn example(x: i32) -> i32 {
   let y = &x;
   sleep(Duration::from_secs(1)).await;
   *y
   }

Prüfen

Das Kernproblem, das durch Pinning gelöst wird, ist die Selbstreferenz, oder ein Future, das einen Zeiger auf sich selbst enthält. Dies tritt auf, wenn ein asynchroner Block eine lokale Variable enthält, die auf eine andere lokale Variable innerhalb des Futures verweist. Hier wäre das y = &x.

---