Restituire std::coroutine_handle da await_suspend abilita il trasferimento simmetrico, una forma garantita di ottimizzazione della chiamata finale (TCO). Quando await_suspend restituisce void, il runtime della coroutine deve tornare al suo chiamante prima di riprendere la successiva coroutine, creando uno stack di chiamate annidato che cresce linearmente con la lunghezza della catena. Restituendo un handle, il compilatore emette un salto diretto (istruzione jmp) al punto di ripresa della coroutine di destinazione, riutilizzando il record di attivazione corrente e mantenendo una profondità di stack costante O(1) indipendentemente dalla lunghezza della catena.
struct SymmetricTransfer { std::coroutine_handle<> next; // Ottimizzato per la chiamata finale: nessuna crescita dello stack std::coroutine_handle<> await_suspend(std::coroutine_handle<>) { return next; } void await_resume() {} bool await_ready() { return false; } };
Abbiamo sviluppato un motore di elaborazione audio in tempo reale per software professionale di produzione musicale. Il sistema utilizzava coroutine C++20 per rappresentare una pipeline di oltre 500 effetti di elaborazione del segnale digitale (DSP) (filtri, compressori, riverberi) collegati insieme. Durante i test di stress, l’applicazione è andata in crash a causa di un overflow dello stack durante il caricamento di rack di effetti complessi, nonostante ogni singola coroutine avesse uno stato locale minimo.
Soluzione 1: await_suspend che restituisce void con ripresa diretta L'implementazione iniziale utilizzava void await_suspend(std::coroutine_handle<>) e richiamava next.resume() internamente. Questo approccio offriva un flusso di codice intuitivo e sequenziale e una facile debug attraverso le stack trace standard. Tuttavia, ogni chiamata a resume() era annidata nella logica di sospensione della coroutine precedente, consumando circa 16KB per fase e esaurendo lo stack del thread di 8MB dopo solo 500 fasi.
Soluzione 2: Coda di lavoro con pianificazione asincrona Abbiamo considerato di sostituire il collegamento diretto con una coda di lavoro centralizzata in cui ogni coroutine inviasse la fase successiva come un elemento di lavoro e si sospendesse immediatamente. Questo garantiva un utilizzo costante dello stack trasformando la ricorsione in iterazione. Il lato negativo era un significativo degrado delle prestazioni: allocazioni dinamiche per i nodi della coda, cache thrashing a causa della contesa dei thread e perdita di località nella cache tra le fasi della pipeline, violando i nostri requisiti di latenza sub-millisecondo.
Soluzione 3: Trasferimento simmetrico tramite coroutine_handle Abbiamo rifattorizzato await_suspend per restituire direttamente il std::coroutine_handle della fase successiva. Questo ha segnalato al compilatore di eseguire TCO, riducendo i frame dello stack. La soluzione ha preservato l'astrazione a costo zero delle coroutine garantendo al contempo un utilizzo di memoria O(1). Il rischio principale riguardava la gestione della durata: una volta restituito l'handle, la coroutine corrente era sospesa e l'accesso a this o a variabili locali dopo il punto di ritorno comportava un comportamento indefinito.
Soluzione scelta e risultato Abbiamo adottato la Soluzione 3. Dopo la rifattorizzazione, la pipeline ha elaborato con successo 512 effetti consecutivi utilizzando solo 4KB di spazio di stack, eliminando i crash e mantenendo prestazioni deterministiche in tempo reale. La modifica ha richiesto attente revisioni del codice per garantire che non esistesse logica dopo il ritorno in await_suspend, ma ha prodotto un’architettura robusta e scalabile.
Perché il trasferimento simmetrico richiede di restituire std::coroutine_handle piuttosto che utilizzare co_await sulla successiva coroutine all'interno di await_suspend? Utilizzare co_await all’interno di await_suspend richiederebbe che la coroutine in attesa fosse completamente sospesa prima, per poi essere ripresa successivamente, il che coinvolge inherentemente il ritorno al runtime e la crescita dello stack. Restituire l'handle direttamente consente al compilatore di trattare la ripresa come una chiamata finale, mentre co_await genera un punto di sospensione asimmetrico che deve preservare il frame del chiamante per riprenderlo successivamente.
Come influisce il trasferimento simmetrico sulla sicurezza delle eccezioni se la coroutine ripresa genera un’eccezione prima di raggiungere il suo punto finale di sospensione? Se la coroutine a cui si trasferisce simmetricamente genera un’eccezione, l’eccezione si dissipa attraverso il frame di await_suspend concettualmente, ma poiché la coroutine originale è già contrassegnata come sospesa, il suo frame deve essere distrutto durante la dissipa dello stack. Questo richiede al compilatore di generare tabelle di gestione delle eccezioni complesse che distruggono la promise della coroutine sospesa e i parametri catturati. I candidati spesso trascurano che gli allocatori di promise_type personalizzati devono gestire correttamente la costruzione parziale, altrimenti si rischiano bug di distruzione doppia durante la dissipa delle eccezioni.
Cosa impedisce di utilizzare il trasferimento simmetrico quando si implementa un generatore che restituisce valori da una struttura dati ricorsiva? I generatori si basano su co_yield per restituire il controllo al chiamante mantenendo il loro stato. Il trasferimento simmetrico passa incondizionatamente il controllo a un'altra coroutine e non torna mai al chiamante originale fino al completamento dell’intera catena. Pertanto, i generatori devono utilizzare una sospensione asimmetrica (restituendo void o true da await_suspend) per consentire al consumatore di ricevere il valore restituito e potenzialmente riprendere il generatore in seguito, piuttosto che forzare un trasferimento irreversibile a un'altra coroutine.