Ressourcenzuständigkeit bei Rust-FFI: den fremden Konstruktor mit seinem tatsächlichen Destruktor paaren

Worum es geht

Das Rustonomicon erklärt, dass fremde Bibliotheken die Zuständigkeit für Ressourcen an die aufrufende Seite übertragen können und dass Wrapper Destruktoren verwenden sollten, um diese Ressourcen freizugeben. Es warnt zudem, dass asynchrone Callbacks aufhören müssen, bevor das anvisierte Rust-Objekt zerstört wird. Ein blosser Rohzeiger kodiert den vollständigen Lebenszyklusvertrag nicht. Rustonomicon: FFI

Warum es wichtig ist

Ein Agent könnte einen erfolgreichen fremden Aufruf als Beleg dafür deuten, dass sein Wrapper sicher ist. Die schwierigen Pfade beginnen oft erst später: ein Initialisierungsfehler, ein Callback, der mit dem Herunterfahren um die Wette läuft, oder zwei Objekte, die glauben, dasselbe Handle zu besitzen. Die vorgeschlagene Methode legt den Lebenszyklus fest, bevor bequeme Methoden entworfen werden.

So wird es angewendet

• Für jede fremde Funktion festhalten, ob sie die Zuständigkeit leiht, überträgt oder zurückgibt. Die genaue dokumentierte Freigabefunktion bestimmen und ob Aufrufe Anforderungen an die Thread-Zugehörigkeit haben.
• Für ein erworbenes Handle eine einzige zuständige Stelle schaffen. Geliehenen Zugriff sichtbar getrennt halten und kein Klonverhalten hinzufügen, bevor die Zuständigkeitssemantik der fremden Bibliothek dies rechtfertigt.
• Teilweise Initialisierung als Abfolge erworbener Ressourcen beschreiben. Für jeden möglichen Fehlschlag festlegen, welche Ressourcen bereits bestehen und welche zuständige Stelle sie freigeben muss.
• Für Callbacks Registrierung, Abmeldung und den Zeitpunkt festlegen, an dem kein Callback mehr unterwegs ist. Den anvisierten Rust-Zustand am Leben halten, bis der fremde Vertrag diesen Zeitpunkt garantiert.
• Fixturen für erfolgreiche Erstellung, fehlgeschlagene Erstellung, wiederholte Operationen, Callback-Zustellung während des Herunterfahrens und normale Freigabe vorschlagen. Freigabeaufrufe über einen kontrollierten Test-Shim beobachten, statt sich nur auf Prozessspeicher-Summen zu verlassen.

Stolpersteine

Ein Destruktor kann keine Garantie für Callback-Ruhe herstellen, die die fremde API nicht bietet. Nicht davon ausgehen, dass eine fremde Allokation mit einem unabhängigen Allokator freigegeben werden kann. Die öffentliche Sicherheitszusage des Wrappers muss zum fremden Vertrag und zu allen Fehlerpfaden passen. Dieses Verfahren belegt keine Sicherheit für eine bestimmte Bibliothek; ungeklärte Regeln zu Zuständigkeit oder Threading erfordern das Nachschlagen in der Dokumentation dieser Bibliothek.