Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128823
Date: Mon, 13 Oct 2025 20:15:05 +0200 (CEST)
To: Larry Garfield <larry@garfieldtech.com>
cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
In-Reply-To: <c2aa62a2-da4b-4caa-99b3-e286ca5ced76@app.fastmail.com>
Message-ID: <4f9b8dfd-5415-3df3-fda9-33a8716c57c1@php.net>
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> <14f591d4-aa1e-49dc-bc20-03cb493dc20c@app.fastmail.com>
 <CAMW7n8C6vSxSEiA=5zntf4Yu9H1yPE+LrG_SZns7YA1Lxim1oA@mail.gmail.com> <CADK1yX+0+Nu9Srqe0CYmDmFWfxRoVrDy=bDnHg6YTmNTwKKtnA@mail.gmail.com> <CAMW7n8BWvf-bE6g7A_0vDW1Lf8hhTm-zuyNEY23DA0biNS-YSA@mail.gmail.com>
 <c2aa62a2-da4b-4caa-99b3-e286ca5ced76@app.fastmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1947501186-1760379305=:167098"
From: derick@php.net (Derick Rethans)

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1947501186-1760379305=:167098
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Mon, 6 Oct 2025, Larry Garfield wrote:

> On Mon, Oct 6, 2025, at 1:50 PM, Edmond Dantes wrote:
>=20
> > Of course, you might say that there are simple websites for which FPM
> > is sufficient. But over the last two years, even for simple sites,
> > there=E2=80=99s TypeScript =E2=80=94 and although its ecosystem may be =
weaker, the
> > language may be more complex for some people, and its performance
> > slightly worse =E2=80=94 it comes with async, WebSockets, and a single
> > language for both frontend and backend out of the box (a killer
> > feature). And this trend is only going to grow stronger.
> >
> > Commercial development of mid-sized projects is the only niche that
> > cannot be lost. These guys need Event-Driven architecture, telemetry,
> > services. And they ask the question: why choose a language that
> > doesn=E2=80=99t support modern technologies. Async is needed specifical=
ly for
> > those technologies, not for FPM.
>=20
> We must have a different definition of mid-sized, because FPM has been=20
> used for numerous mission critical large sites, like government and=20
> university sites, and has been fine.  And such sites still benefit=20
> from faster telemetry, logging, etc.
>=20
> Regardless, we can quibble about the percentages and what people=20
> "should" do; those are all subjective debates.
>=20
> The core point is this: Any async approach in core needs to treat the=20
> FPM use case as a first-class citizen, which works the same way, just=20
> as reliably, as it would in a persistent CLI command.  That is not=20
> negotiable.
>=20
> If for no other reason than avoiding splitting the ecosystem into=20
> async/CLI and sync/FPM libraries, which would be an absolute disaster.

I also agree with this.

I tried reading the RFC today, but I ran out of time. It is *59* page=20
printed (I didn't).

I think we need to be very careful that we do not introduce a feature=20
that allows our users to run into all sorts of problems. The symantics=20
of such a complex feature are going to be really important. Especially=20
about reasoning in which direction the code runs and flows, and how=20
errors are treated.

I recently read=20
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-con=
sidered-harmful/=20
which seems like an entirely sensible way of proceeding. Although the=20
title talks about Go and its problems, the "Structured Concurrency"=20
approach is more of a way of doing concurrency right, without the=20
possibility of our users getting into trouble.

I don't think the RFC as-is is close to this at all =E2=80=94 but I have mo=
stly=20
skimmed it so far.

I would also believe that discussion how this should work would work=20
better with a group of people - preferably in real-time - and not as an=20
idea and implementation of a single person. I know others have been=20
reviewing and commenting on it, but I don't think that's quite the same.

Concurrency in all its forms is a complex subject, and we can't really=20
get this wrong as we'll have to live with the concepts for a long time.

cheers,
Derick

--=20
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/suppo=
rt

mastodon: @derickr@phpc.social @xdebug@phpc.social
--8323329-1947501186-1760379305=:167098--