On Thu, 23 Jul 2026 at 09:59, Edmond Dantes <[email protected]> wrote:
> Hi internals, > > I would like to open the discussion of a new RFC: > > https://wiki.php.net/rfc/async_scheduler_abi > > The proposal gives the engine a coroutine representation and makes the > component that drives coroutines, the scheduler, pluggable by an > extension. It adds no classes, no functions, no constants and no > syntax: the engine compiles in no PHP symbols at all. With no scheduler > registered, PHP behaves exactly as it does today. > > This is not the True Async RFC. It is the minimal engine core extracted > from that work: the activation contract, the notifications the engine > raises, adoption of fibers onto the scheduler, and per-coroutine > storage. Any user-facing API (spawn(), await(), channels) stays in > extension space; True Async is one possible provider on top, not the > subject of this proposal. > > The implementation exists, and I am the one contributing it: > > https://github.com/php/php-src/pull/22561 > > The PR carries the engine changes plus an in-tree reference scheduler > (ext/test_scheduler, disabled by default) that fills every slot from an > ordinary extension; the upstream test suites run unchanged and > schedulerless in the same binary. A bridge extension that registers a > scheduler written in plain PHP exists out of tree, as runtime proof > that the seam is sufficient. > > Points likely of interest for existing code: a scheduler can adopt > fibers started by ReactPHP, Revolt or AMPHP, per fiber and declinable; > the proposal ships the per-coroutine storage that would later let > ob_start() and friends become coroutine-safe; there are no goroutines > and no parallelism, everything runs in one OS thread. > > Feedback is welcome. > > Regards, > Edmond > Hi Edmond, The mailing list is quite busy right now, so I doubt this will get much attention for the time being. I don't see this discussion taking place for at least a couple more months, likely until 8.6 is out and RFCs for the next version start landing. Overall, I really like this idea and approach. I think this is the right path forward. Regarding the note that this "would later let ob_start() and friends become coroutine-safe," I don't think they should be, but that is probably unrelated to this specific RFC. Regards, Seifeddine.
