De geschiedenis van deze vraag gaat terug naar de stabilisering van std::task::Waker in Rust 1.36, die een gestandaardiseerd mechanisme introduceerde voor executors om futures op de hoogte te stellen van gereedheid. Voorafgaand aan dit, vertrouwden async-frameworks op boxed closures of aangepaste notificatietraits die allocatie-overhead met zich meebrachten en naadloze integratie met C-bibliotheken verhinderden. De RawWaker API is ontworpen om zero-cost abstracties te ondersteunen door ontwikkelaars in staat te stellen Waker instanties te construeren vanuit raw pointers en functiepunt-tabellen (RawWakerVTable), die de virtuele tabellen van C++ nabootsen, maar met de veiligheidsvereisten van Rust.
Het probleem ontstaat omdat de constructie van RawWaker het eigendom en het leningssysteem van Rust volledig omzeilt. De programmeur moet handmatig vier kritieke invarianties waarborgen: de datapunten moeten geldig blijven voor de levensduur van alle Waker-klonen (niet alleen de originele), de vier vtable-functies (clone, wake, wake_by_ref, drop) moeten thread-veilig zijn (Send en Sync) zelfs als de executor enkelvoudig is, en de clone-functie moet een nieuwe RawWaker retourneren die verwijst naar dezelfde onderliggende taakstatus. Bovendien moet de vtable de extern "C" ABI gebruiken om FFI-compatibiliteit en stabiele aanroepconventies tussen Rust-versies te waarborgen.
De oplossing vereist strikte naleving van unsafe invarianties. De datavariabele moet typisch verwijzen naar 'static data of gewikkeld zijn in een Arc om gedeeld eigendom over klonen te beheren. De vtable-functies moeten correct verwijzing tellende semantiek implementeren: clone moet de telling verhogen, drop moet deze verlagen, en wake moet verlagen na notificatie (de Waker consumerend). Het schenden van het ABI-contract – zoals het gebruik van Rust aanroepconventies in plaats van extern "C" – resulteert in ongedefinieerd gedrag wanneer de executor deze pointers aanroept, waaronder stackcorruptie, argumentmisalignering of springen naar ongeldige geheugenadressen.
use std::sync::Arc; use std::task::{RawWaker, RawWakerVTable, Waker}; struct TaskState { id: u64, } unsafe fn clone_waker(data: *const ()) -> RawWaker { let arc = Arc::from_raw(data as *const TaskState); let _ = Arc::clone(&arc); let _ = Arc::into_raw(arc); // Lek terug om de drop te vermijden RawWaker::new(data, &VTABLE) } unsafe fn wake_waker(data: *const ()) { let arc = Arc::from_raw(data as *const TaskState); drop(arc); // Drop de Arc, wat de referentie vrijgeeft } unsafe fn wake_by_ref(data: *const ()) { let arc = Arc::from_raw(data as *const TaskState); // Wake logica hier, dan lek terug let _ = Arc::into_raw(arc); } unsafe fn drop_waker(data: *const ()) { let _ = Arc::from_raw(data as *const TaskState); // Impliciete drop geeft geheugen vrij } static VTABLE: RawWakerVTable = RawWakerVTable::new( clone_waker, wake_waker, wake_by_ref, drop_waker, ); fn create_waker(state: Arc<TaskState>) -> Waker { let ptr = Arc::into_raw(state) as *const (); unsafe { Waker::from_raw(RawWaker::new(ptr, &VTABLE)) } }
Stel je voor dat je een high-frequency trading systeem ontwikkelt waarbij een Rust async runtime moet interfacen met een legacy C++ marktdatabon bibliotheek. De C++-bibliotheek biedt een registratiefunctie die een void* context en een functiepointer accepteert, die de callback aanroept wanneer prijsupdates binnenkomen. De technische uitdaging vraagt om het creëren van een Waker die Rust futures verbindt met deze C++ callbackmechanisme zonder per-bericht allocatie-overhead in te voeren, aangezien de latentievereisten sub-microseconde wake-tijden vereisen.
Een oplossing omvatte het opslaan van een Box<dyn Fn() + Send> closure als de datapunten van de Waker. Deze aanpak bood geheugensveiligheid door het eigendomssysteem van Rust en eenvoudige integratie. Echter, het introduceerde onacceptabele heapallocatie latentie voor elke marktdatabon en virtuele dispatch overhead die de zero-copy-architectuur van het systeem schond. Bovendien bleek het beheren van de levensduur van de boxed closure over de FFI grens gevaarlijk, aangezien de asynchrone opruiming van de C++-bibliotheek kan leiden tot dangling pointers als de Rust-zijde de Waker vóór de beëindiging van de C++-bibliotheek stopte met het aanroepen van de callback verliezen.
Een alternatieve aanpak gebruikten een globale statische hash-map die gehele getallen ID's aan taakhandles koppelde, waarbij de ID als de void* context werd doorgegeven. Dit elimineerde allocaties en bood O(1) lookup tijdens de wake-operaties. Toch creëerde dit een geheugenlekgevarend als taken voltooide zonder zich uit de feed te unregisteren, en de statische map vereiste Mutex-synchronisatie die een bottleneck voor contentie werd onder hoge marktdatadoorvoer, wat effectief wake-notificaties over alle CPU-cores serialiseerde.
De gekozen oplossing implementeerde een op maat gemaakte RawWaker waarbij de datapunten een Arc<TaskState> bevatten met de C++-callback context en een voltooiingsvlag. De functies van de RawWakerVTable werden geïmplementeerd als unsafe extern "C" thunks die veilig de void* terug naar Arc pointers transmuteerden, wat ervoor zorgde dat de juiste referentietelling over de FFI grens behouden werd. Dit ontwerp elimineerde per-bericht allocaties door de Arc-structuur te hergebruiken, handhaafde thread-veiligheid door de atomische operaties van Arc, en zorgde voor geheugensveiligheid door de referentietelling alleen te verlagen wanneer het laatste Waker-klon werd gedropt. Het resultaat bereikte sub-microseconde wake-latenties terwijl het geheugensveiligheidsgaranties over de Rust/C++ grens behoudt, en slaagde erin om de ongedefinieerde gedragingdetectie van Miri en stresstests met miljoenen concurrerende prijsupdates te doorstaan.
Waarom moeten de functies van de RawWakerVTable thread-veilig zijn (Send + Sync) zelfs als de executor enkelvoudig is?
Het Waker type implementeert Clone, Send, en Sync, waardoor het over thread-grenzen kan migreren, ongeacht het threadingmodel van de executor. Wanneer een future een Waker vasthoudt en deze doorgeeft aan een spawn_blocking taak of een std::sync::mpsc kanaal, kan de Waker vanuit een andere thread worden aangeroepen dan degene die deze heeft gemaakt. Als de vtable-functies aannemen dat er enkelvoudige toegang is – bijvoorbeeld door Rc of niet-synchroniseerde statische variabelen te gebruiken – creëert dit gegevensraces wanneer wake() gelijktijdig wordt aangeroepen. Bovendien kunnen async runtimes zoals Tokio of async-std taken tussen werkthreads migreren voor load balancing, wat betekent dat de Waker kan worden gekloond en gedropt op threads anders dan de creatieplaats. De vereiste thread-veiligheid waarborgt dat het notificatiemechanisme geldig blijft, ongeacht hoe de Waker door het programma wordt gedeeld.
Welke catastrofale fout doet zich voor als de clone functie een RawWaker retourneert met een andere vtable dan de originele?
Het Waker contract vereist dat alle klonen van een Waker dezelfde onderliggende taak vertegenwoordigen en identiek handelen wanneer ze worden aangeroepen. Als clone een RawWaker retourneert die naar een andere vtable wijst – misschien een die geassocieerd is met een andere taak of null functie pointers bevat – kan de executor de verkeerde wake-logica aanroepen wanneer de taak wordt genotificeerd. Dit resulteert in het ofwel wakker maken van een niet-gerelateerde taak (logische corruptie) of springen naar ongeldige geheugen (segmentatiefout). Concreet slaat de executor doorgaans Waker-klonen op in interne queues; wanneer er een gebeurtenis plaatsvindt, roept hij wake() aan op deze opgeslagen handles. Een mismatched vtable betekent dat de datapunten (taakcontext) door de verkeerde functietekens worden geïnterpreteerd, wat leidt tot onmiddellijke ongedefinieerd gedrag wanneer de vtable-functies de pointer naar een onjuiste type casten of toegang krijgen tot velden op verkeerde offset.