Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128985
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 27 Oct 2025 19:11:22 +0100
To: "Edmond Dantes" <edmond.ht@gmail.com>,
 "Larry Garfield" <larry@garfieldtech.com>
Cc: "php internals" <internals@lists.php.net>
Message-ID: <b4890197-9ecf-412b-a2ba-3f63e12def19@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8D-+t90mQyPLm1N8M0GyKiAS0Z4U0C--=Qj33zSSzuMHQ@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <CAMW7n8BxmAC56LZ4qA6oJp0kFhhPMuLdqfmzeSVQrf6woR9GyA@mail.gmail.com>
 <889d3042-7b3e-4152-bd8c-09bbcc967309@app.fastmail.com>
 <CAMW7n8D-+t90mQyPLm1N8M0GyKiAS0Z4U0C--=Qj33zSSzuMHQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=29d419df8e1e41f48428f3e769f23568
From: rob@bottled.codes ("Rob Landers")

--29d419df8e1e41f48428f3e769f23568
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Mon, Oct 27, 2025, at 18:53, Edmond Dantes wrote:
> > I am not sure how feasible this is, but would there be a way to spli=
t the "async toggle" of IO operations off to its own PR/RFC?
> > To me, that is by far the most important part of this RFC as that's =
the biggest blocker for wider async adoption,
> > but I'm not sure how many layers are needed above it to make it poss=
ible to toggle in a safe fashion.
>=20
> Ah, I think I understand what you mean.
> Yes, from an implementation standpoint, non-blocking behavior is
> provided by the Scheduler API and Reactor API. These two APIs are
> always available anywhere =E2=80=94 in the core, extensions, and so on.
>=20
> However, this isn=E2=80=99t part of the RFC itself, as it belongs to
> implementation details. Moreover, do you remember the first version of
> the RFC? It had a function that explicitly started the Scheduler. So
> indeed, in that first version PHP could be in two states: synchronous
> and asynchronous.
>=20
> What=E2=80=99s the difference in this RFC?
> PHP is **always** in an asynchronous state. Even when executing
> index.php, you can think of it as running inside a coroutine. There=E2=
=80=99s
> just a single coroutine, so no switching occurs (although an extension
> could, for example, create another coroutine =E2=80=94 which is perfec=
tly
> valid).
>=20
> You keep writing your code exactly as before. You don=E2=80=99t need t=
o think
> about PHP being =E2=80=9Casynchronous=E2=80=9D now. As long as you=E2=80=
=99re writing code
> inside a single coroutine, you=E2=80=99re still writing synchronous co=
de.
>=20
> -- Ed

As far as I understand, the only thing missing from php-src that would a=
llow everything to be async is a Fiber scheduler. We already have tons o=
f Fiber libraries out there ... but just no unified scheduler. If we had=
 one of those, then making Fiber-aware i/o functions is "trivial" compar=
ed to implementing this async RFC. If we=E2=80=99re going to merge just =
a scheduler/reactor, it might make more sense to implement a Fiber sched=
uler than a completely new way of doing async.

=E2=80=94 Rob
--29d419df8e1e41f48428f3e769f23568
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Mon, Oct 27, 2025, at 18:53, Edmond Dantes wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt; I am not su=
re how feasible this is, but would there be a way to split the "async to=
ggle" of IO operations off to its own PR/RFC?</div><div>&gt; To me, that=
 is by far the most important part of this RFC as that's the biggest blo=
cker for wider async adoption,</div><div>&gt; but I'm not sure how many =
layers are needed above it to make it possible to toggle in a safe fashi=
on.</div><div><br></div><div>Ah, I think I understand what you mean.</di=
v><div>Yes, from an implementation standpoint, non-blocking behavior is<=
/div><div>provided by the Scheduler API and Reactor API. These two APIs =
are</div><div>always available anywhere =E2=80=94 in the core, extension=
s, and so on.</div><div><br></div><div>However, this isn=E2=80=99t part =
of the RFC itself, as it belongs to</div><div>implementation details. Mo=
reover, do you remember the first version of</div><div>the RFC? It had a=
 function that explicitly started the Scheduler. So</div><div>indeed, in=
 that first version PHP could be in two states: synchronous</div><div>an=
d asynchronous.</div><div><br></div><div>What=E2=80=99s the difference i=
n this RFC?</div><div>PHP is **always** in an asynchronous state. Even w=
hen executing</div><div><a href=3D"http://index.php">index.php</a>, you =
can think of it as running inside a coroutine. There=E2=80=99s</div><div=
>just a single coroutine, so no switching occurs (although an extension<=
/div><div>could, for example, create another coroutine =E2=80=94 which i=
s perfectly</div><div>valid).</div><div><br></div><div>You keep writing =
your code exactly as before. You don=E2=80=99t need to think</div><div>a=
bout PHP being =E2=80=9Casynchronous=E2=80=9D now. As long as you=E2=80=99=
re writing code</div><div>inside a single coroutine, you=E2=80=99re stil=
l writing synchronous code.</div><div><br></div><div>-- Ed</div></blockq=
uote><div><br></div><div>As far as I understand, the only thing missing =
from php-src that would allow everything to be async is a Fiber schedule=
r. We already have tons of Fiber libraries out there ... but just no uni=
fied scheduler. If we had one of those, then making Fiber-aware i/o func=
tions is "trivial" compared to implementing this async RFC. If we=E2=80=99=
re going to merge just a scheduler/reactor, it might make more sense to =
implement a Fiber scheduler than a completely new way of doing async.</d=
iv><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></h=
tml>
--29d419df8e1e41f48428f3e769f23568--