De stabilisatie van async/await in Rust 1.39, samen met het Pin-type dat werd geïntroduceerd in versie 1.33, maakte veilige zelfverwijzende structs mogelijk die cruciaal zijn voor asynchrone toestandsmachines. Deze structuren bevatten vaak interne aanwijzers die verwijzen naar gegevens die eigendom zijn van de struct zelf, zoals buffers en actieve weergaven naar die buffers. Bij het implementeren van handmatige futures of complexe intrusieve datastructuren moeten ontwikkelaars individuele velden toegankelijk maken via Pin<&mut Self>, wat de noodzaak creëert voor veilige projectiemechanismen die de garanties voor geheugenlocatie behouden.
Wanneer een struct via Pin is gepind, garandeert de compiler dat het geheugenadres constant blijft gedurende de levensduur van de pin, mits het type Unpin niet implementeert. Als de struct zelfverwijzende aanwijzers bevat, zoals een rauwe aanwijzer naar een interne vector, zou het verplaatsen van de struct deze aanwijzers ongeldig maken, wat leidt tot hangende verwijzingen. Een naïeve projectiebenadering die eenvoudig Pin<&mut Self> dereferentieert naar &mut Self stelt velden bloot aan veilige Rust-code, die wettelijk mem::swap of mem::replace op die velden zou kunnen aanroepen, waardoor ze uit hun gepinde geheugenlocaties worden verplaatst en de fundamentele pinningovereenkomst wordt geschonden.
Veilige projectie vereist een onveilige conversie die de pinninginvariant behoudt: als de bovenliggende struct !Unpin is, moet de veldprojectie Pin<&mut Field> retourneren in plaats van &mut Field om verplaatsen te voorkomen. De implementatie moet garanderen dat het veld structureel gepind is, wat betekent dat de pinningstatus is gekoppeld aan de pinningstatus van de bovenliggende struct, wat doorgaans wordt bereikt door pointer-arithmetic of Pin::map_unchecked_mut. Voor velden die Unpin implementeren, kan projectie veilig &mut Field retourneren omdat deze types zijn toegestaan om te verplaatsen, zelfs wanneer ze zijn genest binnen gepinde gegevens, hoewel voorzichtigheid geboden is dat dergelijke verplaatsingen andere zelfverwijzende velden niet ongeldig maken.
use std::pin::Pin; use std::marker::PhantomPinned; struct Buffer { data: [u8; 1024], cursor: *const u8, _pin: PhantomPinned, } impl Buffer { // Veilige projectie naar het data-veld (Unpin) fn data_mut(self: Pin<&mut Self>) -> &mut [u8; 1024] { unsafe { &mut self.get_unchecked_mut().data } } // Projectie naar het cursor-veld fn cursor(self: Pin<&mut Self>) -> *const u8 { unsafe { self.get_unchecked_mut().cursor } } }
Context
We bouwden een high-performance, zero-copy parser voor een financieel protocol waarbij berichten sub-bereiken van een herbruikbaar intern buffer konden reference. De parserstatus moest worden gehandhaafd tijdens asynchrone I/O-bewerkingen, wat betekende dat de struct moest worden Pinned om zelfverwijzende aanwijzers naar de buffer toe te staan.
Probleembeschrijving
De Parser-struct hield een Vec<u8> buffer en een &[u8] slice die naar die buffer wijst, die het huidige bericht vertegenwoordigt. Bij het implementeren van Stream voor deze parser ontvangt de poll_next-methode Pin<&mut Self>. We moesten de buffer muteren (om meer gegevens te lezen) terwijl we de geldigheid van de slice-referentie handhaafden, wat zorgvuldige veldprojectie vereiste.
Overwogen oplossingen
Oplossing A: Index-gebaseerde adressering
In plaats van een slice &[u8] op te slaan, slaakten we (usize, usize) indices in de vector op. Voordelen: Volledig veilig, geen Pin-complexiteit, eenvoudig te implementeren. Nadelen: Overhead van runtime-bereikcontroles, minder ergonomische API die handmatig snijden bij elke toegang vereist, potentiële voor indexdesynchronisatiebugs.
Oplossing B: Onveilige Pin-projectie met rauwe aanwijzers
We slaakten het bericht op als een rauwe aanwijzer *const u8 en lengte, terwijl we handmatige projectiemethoden implementeerden met Pin::map_unchecked_mut om toegang te krijgen tot de buffer terwijl het aanwijzer-veld gepind bleef. Voordelen: Zero-cost abstractie, behoudt zelfverwijzendheid, staat directe pointer-arithmetic toe. Nadelen: Vereist unsafe codeblokken, risico van ongedefinieerd gedrag als Pin-invarianten worden geschonden (bijv. Unpin onjuist implementeren).
Oplossing C: Gebruik maken van de pin-project crate
Profiteren van de procedurele macro's om veilige projectiecode automatisch te genereren. Voordelen: Ergonomisch, goed geteste veiligheidinvarianten, vermindert boilerplate. Nadelen: Extra afhankelijkheid, macro-gegenereerde code kan moeilijker te debuggen zijn, lichte compile-tijd kosten.
Gekozen oplossing en resultaat
We kozen voor Oplossing B om externe afhankelijkheden in onze embedded systemen context te vermijden en expliciete controle over geheugenlay-out te behouden. We zorgden ervoor dat de struct Unpin niet implementeerde door PhantomPinned toe te voegen en schreven uitgebreide Miri-tests om de pinninginvarianten te valideren. Het resultaat was een parser die zero-copy semantiek bereikte zonder allocatie per bericht, met een doorvoer van 10Gbps zonder CPU-verzadiging.
Waarom is het onsound om Unpin te implementeren voor een struct die zelfverwijzende aanwijzers bevat?
Unpin geeft specifiek aan dat een type veilig kan worden verplaatst, zelfs wanneer het is gewikkeld in Pin, waardoor veilige code &mut T kan verkrijgen van Pin<&mut T> via methoden zoals Pin::into_inner. Voor een zelfverwijzende struct verandert het verplaatsen van de structuur het geheugenadres van de inhoud, waardoor interne aanwijzers die naar die inhoud verwijzen ongeldig worden. Het implementeren van Unpin zou veilige code toestaan om de struct te verplaatsen terwijl deze gepind is, wat de veiligheidsgarantie schendt die Pin biedt aan asynchrone runtimes en leidt tot use-after-free kwetsbaarheden. Daarom moeten dergelijke structs PhantomPinned gebruiken om expliciet af te zien van Unpin en onopzettelijke auto-implementatie te voorkomen.
Hoe verschilt projectie voor enum-varianten in vergelijking met struct-velden?
Veel kandidaten gaan ervan uit dat de projectiemechanismen identiek zijn voor enums en structs, maar enums presenteren unieke uitdagingen omdat de discriminant bepaalt welke variant actief is. Het projecteren van Pin<&mut Enum> naar een specifieke variant vereist ervoor te zorgen dat de variant gepind blijft terwijl ook wordt voorkomen dat de discriminant verandert, aangezien het wisselen van varianten de onderliggende gegevens zou verplaatsen. Rust heeft geen stabiele ingebouwde ondersteuning voor variantprojectie omdat de discriminant en variantdata overwegingen voor geheugenindeling delen; veilige projectie vereist onveilige code die de actieve variant bevestigt en garandeert dat er geen variantruil plaatsvindt terwijl de enum gepind blijft.
Wat is de rol van PhantomPinned bij het voorkomen van automatische trait-implementaties?
Beginners overzien vaak dat Rust Unpin automatisch implementeert voor de meeste types, tenzij ze expliciet !Unpin velden bevatten, waardoor het omvattingstype standaard !Unpin zou maken. PhantomPinned is een zero-grootte markertype dat expliciet is gedefinieerd als !Unpin, en dient als een negatieve implementatiegrens wanneer het in een struct is opgenomen. Zonder deze marker, zelfs als ontwikkelaars onveilige projectiecode schrijven die veronderstelt dat de struct onbeweeglijk is, zou de compiler Unpin automatisch kunnen implementeren, waardoor veilige code de struct kan extraheren en verplaatsen via Pin::into_inner_unchecked, waardoor onveilige invarianten worden geschonden en ongedefinieerd gedrag wordt opgeroepen.