Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129360
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>
 <tencent_5BEB88F8713676ED0ACF849A@qq.com>
In-Reply-To: <tencent_5BEB88F8713676ED0ACF849A@qq.com>
Date: Fri, 21 Nov 2025 13:36:40 +0200
Message-ID: <CAMW7n8CgyPVw8KizrbGEZXBU2zWA1zbUyTZyH4kvr0qmGRc1Zg@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Hello,

Thank you a lot.

> Swoole=E2=80=99s aim is to leverage PHP=E2=80=99s existing ecosystem rath=
er than build a new one. If we were
> starting from scratch=E2=80=94discarding PHP=E2=80=99s commonly used func=
tions and learning an entirely new
> async API=E2=80=94why wouldn=E2=80=99t developers simply switch languages=
?

And it turned out to be a very successful solution, which has been
proven many times in practice.
The first question developers ask when they want to migrate to async
is: how much code do I need to rewrite?
If the cost of migration is comparable to rewriting the entire project
from scratch, then it becomes economically more sensible to hire Go
developers and rebuild the project.

And PHP=E2=80=99s influence is strong primarily because of the companies th=
at
run PHP-based projects.
So when a company decides to rewrite a project in another language
because PHP no longer meets its technical needs, PHP loses that
client.
That=E2=80=99s why supporting a single runtime and a single API,
standardization, is crucial for the technology=E2=80=99s survival.

Those were the economic reasons. There are technical reasons as well.
In a server that handles multiple requests within a single thread, it
is very important that coroutines do not occupy the CPU for too long.
If they do, all coroutines in that process are affected.
This means that having blocking operations inside a coroutine
nullifies the advantages of concurrency.
Therefore, intentionally making functions blocking so that code works
correctly with shared memory makes the idea of using asynchronous code
**pointless**.

This does not mean that one solution or another is 100 percent
perfect. Each has its drawbacks. The question is whether the drawbacks
outweigh the benefits.
Swoole made it possible to see that, in practice, using a unified API
provides a significant advantage that makes migrating legacy projects
feasible.
This means that by voting for an RFC built on these principles, we are
not venturing into a dark unknown, but walking along a well-trodden
path.

----
Ed