Antwort

Asynchronität in Rust wird durch Future realisiert – ein Objekt, das eine Arbeit darstellt, deren Ergebnis in der Zukunft erhalten wird. Funktionen, die mit async fn deklariert sind, geben eine anonyme Generatorstruktur zurück, die das Trait Future implementiert. Zum Ausführen von asynchronem Code wird ein Runtime (z.B. Tokio oder async-std) verwendet, da die Standardbibliothek keinen eingebauten Event Loop enthält.

Die Hauptmerkmale von Rust:

• Zero-cost abstractions – der Compiler verwandelt async-Code in eine Zustandsmaschine ohne Heap-Allokationen, wenn die Aufgabe es erlaubt.
• Fehlen eines nativen Garbage Collectors – alle Ressourcen werden explizit verwaltet, was besondere Aufmerksamkeit für Lebensdauer und Besitz erfordert.
• Send/Sync – Einschränkungen für die Übertragbarkeit und Synchronisation von Aufgaben zwischen Threads.

Beispiel:

use tokio::time::sleep;
use std::time::Duration;

async fn foo() {
    println!("Hallo");
    sleep(Duration::from_secs(1)).await;
    println!("Welt!");
}

#[tokio::main]
async fn main() {
    foo().await;
}

Trickfrage

Kann eine asynchrone Funktion in Rust standardmäßig sofort bei ihrem Aufruf ausgeführt werden? Warum?

Antwort: Nein. Der Aufruf von async fn gibt nicht das Ergebnis zurück, sondern ein Objekt vom Typ Future (Zustandsmaschine). Für die tatsächliche Ausführung ist es erforderlich, .await aufzurufen oder die Future an die Runtime zu übergeben. Der Aufruf selbst erstellt nur eine Beschreibung der Aufgabe, führt sie jedoch nicht aus.

Beispiel:

async fn answer() -> u32 { 42 }
let fut = answer(); // hier gibt es keine Ausführung, nur Erstellung der future
let result = fut.await; // die Ausführung beginnt hier

Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas

---

Geschichte

In einem Highload-Backend-Projekt hat ein Junior-Entwickler mehrere async-Funktionen deklariert, aber nie .await aufgerufen. Deshalb wurden die Haupt-Threads synchron ausgeführt, was zu einem Performance-Einbruch und einer Verdreifachung der Antwortzeiten führte.

Geschichte

In einem Mikrodienst verwendeten sie eine asynchrone API und interagierten über Tokio. Bei der Migration versuchte ein Entwickler, async-std und Tokio gleichzeitig zu verwenden und vergaß, dass der Event Loop nur einmal vorhanden sein darf. Infolgedessen gab es Hänger und Runtime-Panics, weil beide Runtimes in Konflikt gerieten.

Geschichte

Ein Teammitglied vergaß die Send/Sync-Einschränkungen für die in Future verwendeten Typen. Beim Versuch, eine Future zwischen Threads zu teilen, stürzte die Anwendung mit einem Kompilierungsfehler ab, der die Implementierung von Send für eine bestimmte Struktur erforderte, was eine Überarbeitung der Architektur der Zustandsverwaltung erforderte.