ROADMAP
La sequenza segue i trigger tecnici, non date arbitrarie. Ogni fase deve sbloccare un caso d'uso reale e misurabile.
ORA
Con event dispatcher e sessioni già presenti, il prossimo stress test è il ciclo Request → Response di HttpKernel. In parallelo continuano stream, date, parser edge case e builtin ad alto utilizzo.
PROSSIMO TRIGGER
Quando una rotta Laravel o Symfony gira end-to-end, il progetto raggiunge il primo punto in cui preload, server SAPI e packaging standalone producono valore concreto.
DISTRIBUZIONE
Compilare i moduli una volta all'avvio, mantenere il bytecode residente e incorporare runtime, prelude e applicazione in un artefatto distribuibile.
SERVER RESIDENTE
Una VM pool richiede reset affidabile dello stato locale, assenza di leak e benchmark che dimostrino che il boot per request è davvero il collo di bottiglia.
VISIONE DI LUNGO PERIODO
La VM resta sincrona; un driver esterno sospende e risveglia Fiber su runtime thread-per-core. Questo lavoro ha senso solo quando esistono socket e driver I/O reali da rendere non bloccanti.
NOTA ARCHITETTURALE
Vm::run() una funzione async.Gli Rc<RefCell<…>> rendono VM e valori non trasferibili tra thread. La direzione documentata usa runtime current-thread per core e il meccanismo già esistente di sospensione/ripresa dei frame.
Una nuova capacità non deve rompere i test già verdi né introdurre API che “sembrano” corrette.
Preload, pool e async entrano quando un workload reale dimostra il problema che devono risolvere.
Ogni milestone deve avere suite, numeri e una baseline confrontabile con l'oracolo.
Le divergenze volute vengono documentate; le estensioni si implementano in modo mirato e verificabile.
Dettagli: TODO tecnico ↗ · roadmap async e distribuzione ↗