Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129362
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 13:26:11 +0100
Message-ID: <CAB9bCb0HrXRoN1zn_M2Uhvw2LFs3j9AdOkhA=mZPQQWsAv1cxA@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: bart+php@croquemonsieur.be (Bart Vanhoutte)

Good morning from a rather cold but sunny Belgium,

About Backwards compatibility & colored functions.

Right now, I think there's a problem with the promise of backward
compatibility. Unless your application handles shared state perfectly,
switching on async PHP is going to cause a lot of problems. Ignoring
the problem and asking users to rewrite shared state in their
applications is an absolute no-go from me. On the other hand, we could
go down the path of colored functions, which is also an absolute no-go
from me. We've had this in the past before Fibers were a thing and it
was an absolute pain in the ass. Every function only accepted
Promise<x> and only returned Promise<x>. Bear in mind this coincided
with the rise of static typing and FIG-PSRs where you could get away
with it until Interfaces accepted and returned actual types. Having
colored functions could mean having to duplicate all interfaces where
you would have sync and async ones. This would split the ecosystem in
two and kill adoption, no thanks.

I would much rather have some solution where we can enable (opt-in)
non-blocking/async behavior on a per-project basis. At the very least
we'll be able to use it in greenfields projects. Developers who want
to add support for non-blocking/async I/O in their existing
applications can then rewrite their global state and turn it on
whenever they feel ready for it. It's not ideal but I think it's a
nice compromise between fast adoption and backward compatibility. I
envision a time where you'd look at the documentation of a library and
see "ok, this is async-ready" (shared state is dealt with) through
some badge or something.

---

For people who are questioning whether a feature like this should be
added to PHP I'd like to point out a couple of things.

1. Current usage of async PHP is not a good argument. Like I've
previously said elsewhere, this is a classical chicken-or-egg thing.
Some people think it's not worth adding support for this because
nobody is using it but also very few people are using async PHP
because it's not a first class citizen in the language. Having a
couple of libraries and frameworks supporting whatever async model PHP
ends up choosing would increase these numbers drastically. Adding
support for this new paradigm in popular frameworks/CMSes and thereby
pushing the language and ecosystem forward seems like something the
PHP Foundation was founded for (wrong mailing list, I know).

2. About handing off the problem to Userland: you can _kinda_ do
things asynchronously in PHP through Userland (I'm talking Fibers)
these days, but having async as a first class citizen in PHP core
would make things much easier. Currently, the ecosystem is fragmented
and you need a lot of libraries and specific knowledge in order to get
started. We've been doing this for a couple of years now and only
recently we got a decent ORM to work async (one unit of work per
Fiber, transactions, ...).

3. I think PHP is especially suited for this paradigm. Web
applications require a lot of I/O, whether it is talking to the
client, database, filesystem, API's, ... Having the ability to either
serve multiple requests at the same time through a long running
process or - for example - upload a file to S3 and concurrently write
a record registering that file in the database  can lower the TTFB of
web applications drastically. Moreover, as shared hosting is a thing,
spawning more processes or threads isn't always going to be available.

I feel like not adding async to PHP in the (near?) future would only
be postponing it and risk developers looking to squeeze that extra bit
of performance from their applications to _Go_ to other languages.

---

On a final note, it's nice to see this discussion is gaining some
traction! I've just checked with core ReactPHP developers and they're
checking up on the RFC, however, their main concern seems to be the
same as others on this list: time. Everything is changing very fast
and more time is needed to digest this all and to get used to the idea
of this mentally.

I agree with others, this is something that we have to do right, so
let's take the time to do it right. There's already been an awesome
effort by Edmund, let's keep working on this.

Best Regards,
Bart Vanhoutte

Op vr 21 nov 2025 om 13:08 schreef Edmond Dantes <edmond.ht@gmail.com>:
>
> Hello
>
> > I think you seriously underestimate impact of this in the current PHP c=
ode bases where many applications depend on global state.
> Do I really look like someone who could underestimate memory-related issu=
es? :)
>
> > 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.
> 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.