# [RFC] Concurrency Support in the PHP Engine - Thread: https://externals.io/message/132091 - Original archive: https://news-web.php.net/php.internals/132091 - Started by Edmond Dantes on 2026-07-23T08:58:27+00:00 - Messages: 5 - RFC: Concurrency Support in the PHP Engine (Under discussion) — https://externals.io/rfc/async_scheduler_abi.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #132091 — Edmond Dantes — 2026-07-23T08:58:27+00:00 URL: https://externals.io/message/132091#132091 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 --- ## #132092 — Seifeddine Gmati — 2026-07-23T09:56:52+00:00 URL: https://externals.io/message/132091#132092 · In reply to: #132091 > 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. --- ## #132093 — Edmond Dantes — 2026-07-23T10:06:41+00:00 URL: https://externals.io/message/132091#132093 · In reply to: #132092 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 --- ## #132826 — Edmond Dantes — 2026-10-07T10:17:33+00:00 URL: https://externals.io/message/132091#132826 · In reply to: #132091 Hello everyone I’ve started integrating the codebase with the Scheduler API + Poll API (https://discourse.thephp.foundation/t/php-dev-rfc-polling-api-additions/6158) to test these RFCs for bugs. The implementation is still fairly rough, but I think the situation will change significantly over the next 2–3 months. I’ll post an update here later with the results. P.S. Heh, the bugs I’ve found so far were in completely different modules as well. :) чт, 23 июл. 2026 г. в 11:58, Edmond Dantes : > > 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 --- ## #132828 — Edmond Dantes — 2026-10-07T10:33:01+00:00 URL: https://externals.io/message/132091#132828 · In reply to: #132826 Just a couple of weeks ago, I had no hope that async could make it into the language core. But now we have both halves: Scheduler + IO Hooks. Getting both RFCs into shape is absolutely achievable. Having them ready for a vote before next summer is more than realistic. So let’s make it happen together! Best regards, Ed