Tokio-Send-Fehler: den über await hinweg erhaltenen Zustand untersuchen

Worum es geht

Tokio dokumentiert, dass mit tokio::spawn gestartete Tasks Send sein müssen, weil sie sich während der Suspendierung zwischen Threads bewegen können. Der wichtige Zustand ist das, was über einen await-Punkt hinweg lebendig bleibt. Ein nicht-Send-Wert, der vollständig verwendet und verworfen wird, bevor die Suspendierung eintritt, unterscheidet sich von demselben Wert, der zur späteren Verwendung erhalten bleibt. Tokio: Tasks starten

Warum es wichtig ist

Ein Agent kann auf den Compiler reagieren, indem er Objekte klont oder jeden Zeiger durch einen nebenläufigkeitsfähigen Typ ersetzt. Das kann die Eigentümerschaft verschleiern und den tatsächlich suspendierten Zustand unverändert lassen. Den Fehler als Wegweiser zu dem vom Future erhaltenen Wert nutzen und dann entscheiden, ob das Erhalten notwendig ist.

So wird es angewendet

• Den vom Compiler benannten Wert und den await-Punkt lokalisieren, der seine Lebensdauer kreuzt. Die Funktion verkleinern, dabei diese Beziehung erhalten, damit der Grund sichtbar bleibt.
• Wird der Wert nur synchron benötigt, diese Arbeit in einen klaren inneren Scope legen und ein eigenes, für die spätere Verwendung geeignetes Ergebnis extrahieren. Prüfen, dass der Wert nicht mehr über die Suspendierung hinweg erhalten bleibt.
• Muss der Zustand fortbestehen, ein Eigentümerschafts- und Synchronisierungsdesign wählen, das den tatsächlichen Anforderungen an gemeinsame Nutzung entspricht. Kein unsicheres Send als mechanische Reaktion auf einen Compiler-Fehler hinzufügen.
• Ist die Operation absichtlich auf einen Thread beschränkt, ein dokumentiertes Local-Task-Design separat untersuchen, statt so zu tun, als erfülle es den gewöhnlichen Spawn-Vertrag.
• Eine Kompilierprüfung für den verkleinerten Fall sowie Verhaltenstests für Abbruch, gemeinsame Aktualisierungen und Ergebniszustellung im tatsächlichen Task-Arrangement vorschlagen.

Stolpersteine

Ein Future Send zu machen belegt nicht, dass sein Algorithmus frei von Races, Deadlocks oder blockierender Arbeit ist. Ebenso steuert async move die Eigentümerschaft bei der Erfassung, macht aber nicht automatisch jeden erfassten Typ Send. Dieser Artikel schlägt Diagnose- und Validierungsschritte vor; er behauptet weder eine Laufzeit-Performance-Änderung noch einen ausgeführten Scheduler-Test.