Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128788
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 06 Oct 2025 10:28:07 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <14f591d4-aa1e-49dc-bc20-03cb493dc20c@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8BTb1OHdLsjD+fPyeGOkYSQx-KXMrLnG-4rVUSq2646+Q@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <CADuktwNP+t-DJbLCsnHHhztZYmOMGYde9rzNm+9B0SUsrNvV-g@mail.gmail.com>
 <CAMW7n8BTb1OHdLsjD+fPyeGOkYSQx-KXMrLnG-4rVUSq2646+Q@mail.gmail.com>
Subject: Re: [PHP-DEV] 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 6, 2025, at 12:34 AM, Edmond Dantes wrote:
> Hello.
>
>> Just a quick question - other methods that tried to provide async/par=
allel type functionality previously were only available via the CLI.
>
> TrueAsync itself is integrated into PHP in such a way that it is
> always active. The scenario you described is technically possible (Of
> course, this can also be useful for sending telemetry in a way that
> doesn=E2=80=99t interfere with request processing.), but it=E2=80=99s =
not particularly
> relevant in the context of modern development.
>
> Why?
>
> Because client requests are usually processed sequentially, step by
> step. Parallel tasks are rare.=20

This is simply not true.  The example you're replying to is quite common.

It's even more common for the database.  WordPress, Drupal, and many oth=
er such systems frequently run different DB queries to build different c=
omponents of a page.  (Blocks, widgets, components, the names differ.)  =
Being able to do those in parallel is a natural optimization that we wer=
e thinking about in Drupal nearly 15 years ago, but it wasn't viable at =
the time.

> Therefore, from the server=E2=80=99s
> perspective, the main benefit of concurrency is the ability to handle
> multiple requests within a single process.

That is *A benefit*.  It is not the *only benefit*.  Being able to compr=
ess the time of each request in a shared-nothing model is absolutely val=
uable.

Remember, in the wild, PHP-FPM and mod_php are by orders of magnitude th=
e most common ways PHP is executed.  React, Swoole, etc. are rounding er=
rors in most of the market.  And the alternate runtime with the most mom=
entum is FrankenPHP, which reuses processes but is still "one request in=
 a process at a time."

> The same thing that Swoole,
> AMPHP, and other modern backend solutions do.
>
> And this is one of the reasons why FPM is morally outdated and

I am going to assume this is a translation issue, because "morally outda=
ted" is the wrong term here.  "Morally outdated" is how you'd describe "=
racial segregation is good, actually."  Not "this technology is slower t=
han we need it to be."  You probably mean "severely outdated" or somethi=
ng along those lines.

Which, as I explained above, is simply not true.  PHP is going to be run=
ning in a mostly shared-nothing environment for the foreseeable future. =
 Those use cases still would benefit from async support.

--Larry Garfield