Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128982
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 27 Oct 2025 11:37:50 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <aa5d900e-ae63-4e60-b46c-404b27e7fcc3@app.fastmail.com>
In-Reply-To: 
 <CAAwdEzA6Wr2OxwqoFb3kJXvceRFUdYi4o7uHc7mTV5Men7=dOg@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <CAMW7n8BxmAC56LZ4qA6oJp0kFhhPMuLdqfmzeSVQrf6woR9GyA@mail.gmail.com>
 <889d3042-7b3e-4152-bd8c-09bbcc967309@app.fastmail.com>
 <CAAwdEzA6Wr2OxwqoFb3kJXvceRFUdYi4o7uHc7mTV5Men7=dOg@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Oct 27, 2025, at 11:18 AM, Alexandru P=C4=83tr=C4=83nescu wrote:
>>=20
>>=20
>> On Mon, Oct 27, 2025 at 6:05=E2=80=AFPM Larry Garfield <larry@garfiel=
dtech.com> 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, tha=
t is by far the most important part of this RFC as that's the biggest bl=
ocker for wider async adoption, but I'm not sure how many layers are nee=
ded above it to make it possible to toggle in a safe fashion.
>>=20
>> Hi!
>>=20
>> Can you clarify what you mean by "async toggle"?
>> Is it the actual implementation that would use async constructs if th=
e current context is a coroutine for each implementation of IO functions?
>> Yes, for that, it would be nice to have separate PRs, even multiple o=
nes for easier review. But maybe you mean something else...
>> =20
>> --=20
>> Alex

The most important feature of this RFC, IMO, is that when async is "acti=
ve", all IO operations become non-blocking and automatically suspend an =
active coroutine, so that other coroutines can act.  That means you can =
write file_get_contents() or whatever, and in non-async land it will blo=
ck as normal, but in async land it will suspend and let other coroutines=
 run, then pick up again when ready, without requiring any code changes.

(At least that's how I understand that part of the RFC.)

That is *huge*, and easily the most important feature.  Really, if we ha=
d that in core it would be possible to do most of the rest in user-space=
 with the existing Fibers, I suspect.  But I don't know how feasible it =
is to separate that part out, in large part because it would mean exposi=
ng some kind of way to toggle if async is "active" (for some definition =
of active).  But if that is possible/feasible, that would be a much narr=
ower, more easily reviewable, and still highly useful RFC that could be =
iterated on in both user space and core.

I do not know how coupled that is to the new Fiber-incompatible loop, wh=
ich is the biggest problem.

--Larry Garfield