On Thu, 23 Jul 2026 at 09:59, Edmond Dantes <edmond.ht@gmail.com> 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.
