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 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.
Hi Seifeddine,
Yes, perhaps this discussion has started a bit too early. But there's
no rush. I think waiting a couple of months is perfectly fine.
Regarding the note that this "would later let
ob_start()and friends become coroutine-safe,"
I just wanted to mention that the possibility has been considered in
advance. Whether to actually use it or not can always be decided in a
separate RFC.
What's important to me is that this RFC doesn't rule out that possibility.
Regards, Ed