Das Copy-Trait entstand in der frühen Gestaltung von Rust als Marker für Typen, die durch eine einfache bitweise Kopie ohne Bedenken hinsichtlich der Ressourcenverwaltung dupliziert werden können. Drop wurde eingeführt, um eine deterministische Ressourcenbereinigung für Typen zu handhaben, die externe Ressourcen wie Dateideskriptoren oder Heap-Speicher verwalten. Der Konflikt zwischen impliziter Duplizierung und einzigartigem Besitz wurde offensichtlich, als die Entwickler bemerkten, dass bitweise Kopien nicht teilbare Ressourcenhandles gemeinsam nutzen würden. Folglich wurde der Compiler so gestaltet, dass er jeden Typ, der beide Traits gleichzeitig implementieren möchte, ablehnt.
Wenn ein Typ, der Drop implementiert (z. B. zur Verwaltung eines Dateideskriptors), auch Copy wäre, würde die Zuweisung des Wertes an eine neue Variable zwei bitweise identische Kopien erzeugen. Wenn beide Kopien den Gültigkeitsbereich verlassen, wird die benutzerdefinierte Drop-Implementierung zweimal auf die gleiche zugrunde liegende Ressource ausgeführt. Dies führt zu einer Double-Free-Schwachstelle oder Use-After-Free, wenn die Ressource durch den ersten Drop ungültig wird, aber vom zweiten Zugriff darauf zugegriffen wird, was die Speichersicherheit gefährdet.
Der Rust-Compiler enthält eine Kohärenzprüfung im Trait-System, die ausdrücklich verbietet, dass ein Typ sowohl Copy als auch Drop implementiert. Diese Einschränkung zwingt Entwickler dazu, Clone (explizite Duplizierung) für Typen zu verwenden, die eine benutzerdefinierte Zerstörung erfordern, wodurch die Implementierung ordnungsgemäß Referenzzählungen erhöhen oder tiefe Kopien durchführen kann. Indem sichergestellt wird, dass jede logische Entität eine entsprechende einzigartige Löschung hat, erhält das Typsystem nullkosten Abstraktionen, ohne Sicherheitsgarantien zu opfern.
Betrachten Sie eine DatabaseHandle-Struktur, die einen Rohzeiger auf ein Verbindungsobjekt in einer externen C-Bibliothek umhüllt. Die Anwendung erfordert, dass Handles durch Wertübergabe in mehreren Closures für die Protokollierung übergeben werden, wobei jedes Handle seine einzigartige Verbindung über einen FFI-Aufruf beim Droppen schließen muss. Wenn das Handle Copy wäre, würde die implizite Duplizierung mehrere Handles erstellen, die den Besitz derselben zugrunde liegenden C-Ressource beanspruchen, was zwangsläufig zu doppelten Schließungen oder Use-After-Free führt, wenn der Gültigkeitsbereich endet.
Ein Ansatz war, Copy zuzulassen und Drop mit interner Referenzzählung unter Verwendung von Arc zu implementieren. Dies würde Synchronisationsüberhead für jedes Handle hinzufügen, die Binärgröße und die Laufzeitkosten bei allen Operationen erhöhen. Es würde auch die FFI-Grenze komplizieren, bei der der Rohzeiger atomar aus dem Arc extrahiert werden muss, was potenzielle Deadlocks einführt, wenn die Drop-Logik selbst einen Rückruf in den Rust-Code vornimmt.
Ein weiterer Ansatz erforderte die Verwendung von Copy, aber mit der Dokumentation, dass die Benutzer eine close-Methode manuell aufrufen müssen, bevor der Wert verworfen wird. Dies legt die Verantwortung für die Speichersicherheit vollständig beim Programmierer ab, was das Kernprinzip von Rust verletzt, Fehler zur Compile-Zeit zu verhindern. Es führt unvermeidlich zu Ressourcenlecks, wenn Entwickler vergessen, close aufzurufen, oder zu doppelten Schließungen, wenn sie das Handle unbeabsichtigt kopieren und versuchen, beide Kopien zu schließen.
Die gewählte Lösung bestand darin, Copy zu entfernen und Clone manuell zusammen mit Drop zu implementieren. Clone führt eine tiefe Kopie durch, indem eine neue Datenbankverbindung geöffnet wird, um sicherzustellen, dass jede Instanz ihre eigene Ressource besitzt und eine Aliasing des zugrunde liegenden C-Zeigers verhindert wird. Drop schließt nur die eigene Verbindung, während der Compiler versehentliche bitweise Kopien verhindert, wodurch die Sicherheit ohne Laufzeitüberhead gewahrt bleibt.
Das Typsystem verhindert nun versehentliche Kopien zur Compile-Zeit und zwingt Entwickler dazu, explizit clone aufzurufen, was die Ressourcenbeschaffung im Quellcode sichtbar macht. Das Programm vermeidet Double-Free-Fehler, wenn Handles in Threads oder Closures übergeben werden, und die deterministischen Zerstörungsgarantien bleiben intakt, ohne atomare Operationen oder manuelle Speicherverwaltung erforderlich zu machen.
Warum kann ich Copy nicht für eine Struktur ableiten, die einen Vec enthält?
Ein Vec besitzt heap-zugewiesenen Speicher und implementiert Drop, um diesen Speicher freizugeben, wenn der Vektor den Gültigkeitsbereich verlässt. Wenn eine Struktur, die einen Vec enthält, Copy wäre, würde die bitweise Duplizierung zwei Strukturen erzeugen, die auf dasselbe Heap-Puffer auf dem Stack zeigen, aber beide würden denselben Zeiger auf den Heap enthalten. Wenn die erste Struktur verworfen wird, wird der Speicher freigegeben; wenn die zweite verworfen wird, versucht sie, denselben Speicher erneut freizugeben, was zu undefiniertem Verhalten führt. Rust verhindert dies, indem es verlangt, dass alle Felder eines Copy-Typs ebenfalls Copy sein müssen, um rekursiv sicherzustellen, dass keine verschachtelten Drop-Implementierungen existieren.
Verhindert mem::forget die Probleme mit Copy und Drop?
std::mem::forget verbraucht einen Wert, ohne seinen Zerstörer auszuführen, betrifft jedoch nur einen bestimmten besessenen Wert, nicht alle Kopien davon. Wenn Copy und Drop erlaubt wären, würde das Vergessen einer Kopie nicht verhindern, dass andere bitweise Kopien ihre Drop-Implementierungen beim Verlassen des Gültigkeitsbereichs ausführen. Diese verbleibenden Löschungen würden weiterhin versuchen, die gleiche zugrunde liegende Ressource freizugeben, was zu Use-After-Free oder Double-Free führen würde, unabhängig von der vergessenen Instanz.
Kann ich ManuallyDrop verwenden, um Copy sicher zu implementieren?
Das Einwickeln eines Feldes in ManuallyDrop verhindert die automatische Ausführung von Drop, was es technisch dem äußeren Struct ermöglicht, Copy abzuleiten. Dies verschiebt jedoch die Verantwortung zur Aufruf von ManuallyDrop::drop auf den Benutzer für jede einzelne erstellte Kopie, was effektiv ein manuelles Speicherverwaltungsszenario schafft. Wenn der Benutzer vergisst, auch nur eine Kopie zu löschen, treten permanente Ressourcenverluste auf; Rust verbietet dieses Muster für ressourcenbesitzende Typen, da es die Sicherheitsgarantie einer deterministischen, automatischen Bereinigung untergräbt.