Re: [PHP-DEV] [RFC] Concurrency Support in the PHP Engine

--000000000000336a830657444783
Content-Type: text/plain; charset="UTF-8"

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.

--000000000000336a830657444783
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

--000000000000336a830657444783--