Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129365
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8D0QshP8VhGOUqVnC+Uwf88TC_yy_mQdeNZW_go5YLdcw@mail.gmail.com>
 <C58ADF49-6E21-4E25-8859-2A0769829E38@php.net> <e8625214-1c6f-40b8-b24f-e592e6f92012@beccati.com>
 <CAMW7n8Dy3=QyCrG4BMwVXWAipgOr2Vyhy_jbLVTYeq2Jc5v15g@mail.gmail.com>
 <dbc31109-a43d-4afc-9f4f-62c6439328e5@rwec.co.uk> <ea59722c-2c84-4a59-a442-a8b217ff577d@gmail.com>
 <b151687a-f4bd-48cf-90e6-440f763ccd6b@rwec.co.uk> <CAMW7n8CLZ7yFhUhh89wx7L+YwQ25LA7HZoGWUFB3R76KgXko2w@mail.gmail.com>
 <CAEKnhAHRPbiU4auDuTtFL2ueNnACjmYm_ff9c3VciYE9HfeGZg@mail.gmail.com> <CAMW7n8D5B=XVX_Jes+LV=2fPwjQr_RBVphPi_Cxm8-_Rwpdo_Q@mail.gmail.com>
In-Reply-To: <CAMW7n8D5B=XVX_Jes+LV=2fPwjQr_RBVphPi_Cxm8-_Rwpdo_Q@mail.gmail.com>
Date: Fri, 21 Nov 2025 10:06:30 -0300
Message-ID: <CADK1yX+jGtqQVYFTo5YmkenPrNcXz7Dd7RCUKWGrq+50pnKOnw@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Edmond Dantes <edmond.ht@gmail.com>
Cc: Jakub Zelenka <bukka@php.net>, "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="00000000000098151d06441a7db1"
From: deleugyn@gmail.com (Deleu)

--00000000000098151d06441a7db1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 21 Nov 2025 at 09:08 Edmond Dantes <edmond.ht@gmail.com> wrote:

> Hello
>
> > I think you seriously underestimate impact of this in the current PHP
> code bases where many applications depend on global state.
> Do I really look like someone who could underestimate memory-related
> issues? :)
>
> > Now imagine that some popular plugin decides to use async which change
> some of its globals (like $post or $wp_query) during the suspension of th=
e
> main code. I would assume this could horribly break things.
> Or for example, you run an old WordPress on the new PHP 8.5 and
> everything breaks. Is that a reason not to release new PHP versions?
> No, I=E2=80=99m not joking. That=E2=80=99s literally the essence of the a=
rgument. If
> something might break, then we shouldn=E2=80=99t do it?
>
> This is a common story. There is a framework that is adapted to a
> technology, and there is a framework or library that is not adapted to
> it.
> If a framework is not adapted, you simply won=E2=80=99t be able to use th=
e
> technology. So why is this considered a problem?
> However, inside WordPress you will still be able to use coroutines as
> long as you don=E2=80=99t call WP functions that aren=E2=80=99t adapted. =
You can. So
> why is this a problem?
>
> I can use AMPHP inside WordPress and break WP.
> So does that mean we must urgently remove Fiber from the language?
> Because AMPHP uses Fiber, and AMPHP implements coroutines. And
> coroutines break WordPress.
> Asynchrony already exists in PHP. You can write async code today.
> Which means you can already do all the =E2=80=9Chorrors=E2=80=9D you=E2=
=80=99re talking about.
> TrueAsync cannot change that. And no one else can change it either.
> So why is this being treated as an argument against it?
>
> > Don't forget that other code don't have control over the plugin and it
> might not even know that async is used there.
> Exactly. This means that right now I can use Fiber plus select() to
> write async code and break WordPress.
> And I can also write a plugin that divides by zero and crashes
> WordPress, and WordPress won=E2=80=99t know anything about it.
>
> > So I'm not sure if this design is compatible with WordPress
>
> Yes, WordPress is not compatible with asynchrony. I=E2=80=99ll emphasize
> again. This is not about TrueAsync specifically. This is about
> asynchrony itself. Yes, WordPress and Laravel are not compatible with
> concurrent execution. That=E2=80=99s true.
> But are you **really suggesting** that because of this, all other
> applications should be denied the ability to use it?
> Moreover, would you deny WordPress itself the possibility of
> supporting asynchrony in future? After all, WordPress can be
> refactored. It=E2=80=99s not carved in stone.
>
> Wouldn=E2=80=99t WordPress benefit from the performance improvements that
> async provides?
> Wouldn=E2=80=99t WordPress plugins benefit from being able to actively
> communicate with microservices and deliver the fastest possible
> responses to JavaScript?
>
> Is this feature really something nobody needs? If yes, then I have no
> further questions.
>
> Async is needed to increase throughput. That=E2=80=99s the purpose. If a =
PHP
> project doesn=E2=80=99t need it, it doesn=E2=80=99t have to use it. That=
=E2=80=99s fine. But
> there are PHP projects that do need it.



The point you=E2=80=99re trying to make here is very clouded for me. Althou=
gh you
can use AMPHP to break Wordpress, there is an extensive process of =E2=80=
=9Copt-in=E2=80=9D
for you to do that and it doesn=E2=80=99t happen naturally, accidentally or
unintentionally. You=E2=80=99ll have to setup a plugin that requires AMPHP =
and
write some code that will inadvertently break and never really see the
light of day.

Now there=E2=80=99s 2 possibilities for us to go from here: my understandin=
g of the
most basic concept of TrueAsync is still wrong OR the comparison you=E2=80=
=99re
trying to make isn=E2=80=99t relevant.

My understanding is that if this RFC were to be implemented as-is, you
would be able to open any PHP file and write \Async\spawn() and: nothing
would blow up but any code inside the project that touches global state
could silently misbehave. Is this not true?

My understanding of AMPHP is that things only become async if you
explicitly run AMPHP as your web server. It either has no effect if your
application is running Apache + mod_php OR your application 100% breaks
with nothing getting executed at all. Is this not true?

I know you're tired of debating very basic things, but from the
conversation on the list, I think I'm not the only one confused by this. We
did talk about our desire to have Async on PHP-FPM and as far as I remember
you mentioned it not being very useful, but that it would be possible
nonetheless. This is the a core principle that matters a lot.

Here is a very simple hypothetical:
Suppose I run a website and I have very little understanding of PHP, but I
know the basics. Every Monday I run `composer update`, do a little testing
and deploy the website. Suppose next Monday when I run `composer update`
one of my dependencies (Package A) starts to pull in AMPHP as its nested
dependency. When I try to open my website locally it will either have
everything broken or it will just work regularly and nothing will be
running async. There is no other option.
Now suppose the same example but with PHP 9 + TrueAsync. I do `composer
update` one day and test my home page and it works. But deeply nested
somewhere there is a feature that will use Package A which then spawns a
coroutine and leads to my global state code behaving weirdly. It's not a
fatal error. It's not very clear at all to me that something changed, but
now my array indexes are triggering DB updates out of order.

If my assumptions about TrueAsync are completely wrong and that's not
possible at all, I think that's not clear for everyone. But if my
assumptions are right, then your comparison with AMPHP is not the same
thing.

--00000000000098151d06441a7db1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"auto">On Fri, 21 Nov 2025 at 09:08 Edmond Dant=
es &lt;<a href=3D"mailto:edmond.ht@gmail.com" target=3D"_blank">edmond.ht@g=
mail.com</a>&gt; wrote:<br></div><div dir=3D"auto"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-colo=
r:rgb(204,204,204)">Hello<br>
<br>
&gt; I think you seriously underestimate impact of this in the current PHP =
code bases where many applications depend on global state.<br>
Do I really look like someone who could underestimate memory-related issues=
? :)<br>
<br>
&gt; Now imagine that some popular plugin decides to use async which change=
 some of its globals (like $post or $wp_query) during the suspension of the=
 main code. I would assume this could horribly break things.<br>
Or for example, you run an old WordPress on the new PHP 8.5 and<br>
everything breaks. Is that a reason not to release new PHP versions?<br>
No, I=E2=80=99m not joking. That=E2=80=99s literally the essence of the arg=
ument. If<br>
something might break, then we shouldn=E2=80=99t do it?<br>
<br>
This is a common story. There is a framework that is adapted to a<br>
technology, and there is a framework or library that is not adapted to<br>
it.<br>
If a framework is not adapted, you simply won=E2=80=99t be able to use the<=
br>
technology. So why is this considered a problem?<br>
However, inside WordPress you will still be able to use coroutines as<br>
long as you don=E2=80=99t call WP functions that aren=E2=80=99t adapted. Yo=
u can. So<br>
why is this a problem?<br>
<br>
I can use AMPHP inside WordPress and break WP.<br>
So does that mean we must urgently remove Fiber from the language?<br>
Because AMPHP uses Fiber, and AMPHP implements coroutines. And<br>
coroutines break WordPress.<br>
Asynchrony already exists in PHP. You can write async code today.<br>
Which means you can already do all the =E2=80=9Chorrors=E2=80=9D you=E2=80=
=99re talking about.<br>
TrueAsync cannot change that. And no one else can change it either.<br>
So why is this being treated as an argument against it?<br>
<br>
&gt; Don&#39;t forget that other code don&#39;t have control over the plugi=
n and it might not even know that async is used there.<br>
Exactly. This means that right now I can use Fiber plus select() to<br>
write async code and break WordPress.<br>
And I can also write a plugin that divides by zero and crashes<br>
WordPress, and WordPress won=E2=80=99t know anything about it.<br>
<br>
&gt; So I&#39;m not sure if this design is compatible with WordPress<br>
<br>
Yes, WordPress is not compatible with asynchrony. I=E2=80=99ll emphasize<br=
>
again. This is not about TrueAsync specifically. This is about<br>
asynchrony itself. Yes, WordPress and Laravel are not compatible with<br>
concurrent execution. That=E2=80=99s true.<br>
But are you **really suggesting** that because of this, all other<br>
applications should be denied the ability to use it?<br>
Moreover, would you deny WordPress itself the possibility of<br>
supporting asynchrony in future? After all, WordPress can be<br>
refactored. It=E2=80=99s not carved in stone.<br>
<br>
Wouldn=E2=80=99t WordPress benefit from the performance improvements that<b=
r>
async provides?<br>
Wouldn=E2=80=99t WordPress plugins benefit from being able to actively<br>
communicate with microservices and deliver the fastest possible<br>
responses to JavaScript?<br>
<br>
Is this feature really something nobody needs? If yes, then I have no<br>
further questions.<br>
<br>
Async is needed to increase throughput. That=E2=80=99s the purpose. If a PH=
P<br>
project doesn=E2=80=99t need it, it doesn=E2=80=99t have to use it. That=E2=
=80=99s fine. But<br>
there are PHP projects that do need it.</blockquote><div dir=3D"auto"><br><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">The point you=E2=80=99re=
 trying to make here is very clouded for me. Although you can use AMPHP to =
break Wordpress, there is an extensive process of =E2=80=9Copt-in=E2=80=9D =
for you to do that and it doesn=E2=80=99t happen naturally, accidentally or=
 unintentionally. You=E2=80=99ll have to setup a plugin that requires AMPHP=
 and write some code that will inadvertently break and never really see the=
 light of day.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Now there=
=E2=80=99s 2 possibilities for us to go from here: my understanding of the =
most basic concept of TrueAsync is still wrong OR the comparison you=E2=80=
=99re trying to make isn=E2=80=99t relevant.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">My understanding is that if this RFC were to be implem=
ented as-is, you would be able to open any PHP file and write \Async\spawn(=
) and: nothing would blow up but any code inside the project that touches g=
lobal state could silently misbehave. Is this not true?</div><div dir=3D"au=
to"><br></div><div dir=3D"auto">My understanding of AMPHP is that things on=
ly become async if you explicitly run AMPHP as your web server. It either h=
as no effect if your application is running Apache=C2=A0+ mod_php OR your a=
pplication 100% breaks with nothing getting executed at all. Is this not tr=
ue?</div><div dir=3D"auto"><br></div><div>I know you&#39;re tired of debati=
ng very basic things, but from the conversation on the list, I think I&#39;=
m not the only one confused by this. We did talk about our desire to have A=
sync on PHP-FPM and as far as I remember you mentioned it not being very us=
eful, but that it would be possible nonetheless. This is the a core princip=
le that matters a lot.</div><div><br></div><div>Here is a very simple hypot=
hetical:=C2=A0</div><div>Suppose I run a website and I have very little und=
erstanding of PHP, but I know the basics. Every Monday I run `composer upda=
te`, do a little testing and deploy the website. Suppose next Monday when I=
 run `composer update` one of my dependencies (Package A) starts to pull in=
 AMPHP as its nested dependency. When I try to open my website locally it w=
ill either have everything broken or it will just work regularly and nothin=
g will be running async. There is no other option.</div><div>Now suppose th=
e same example but with PHP 9=C2=A0+ TrueAsync. I do `composer update` one =
day and test my home page and it works. But deeply nested somewhere there i=
s a feature that will use Package A which then spawns a coroutine and leads=
 to my global state code behaving weirdly. It&#39;s not a fatal error. It&#=
39;s not very clear at all to me that something changed, but now my array i=
ndexes are triggering DB updates out of order.</div><div><br></div><div>If =
my assumptions about TrueAsync are completely wrong and that&#39;s not poss=
ible at all, I think that&#39;s not clear for everyone. But if my assumptio=
ns are right, then your comparison with AMPHP is not the same thing.</div><=
div><br></div></div></div>
</div>

--00000000000098151d06441a7db1--