Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128890
Date: Tue, 21 Oct 2025 23:07:30 +0100 (BST)
To: Edmond Dantes <edmond.ht@gmail.com>
cc: Larry Garfield <larry@garfieldtech.com>, 
    php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
In-Reply-To: <CAMW7n8CAd3P1egRkeHBsrMk7YOEdiSvVgm5teyCZ7EOysC7q1g@mail.gmail.com>
Message-ID: <236bd059-4ab5-1798-17f0-233be93aaaf4@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>
 <4f9b8dfd-5415-3df3-fda9-33a8716c57c1@php.net> <CAMW7n8BG=GsqrQ-D6rekRgYOg0y_SUJksio7Y-uQKSs97zixEg@mail.gmail.com> <d4c99ddc-d62f-4574-a798-80fa7b1d3e1c@app.fastmail.com> <CAMW7n8CAd3P1egRkeHBsrMk7YOEdiSvVgm5teyCZ7EOysC7q1g@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-670500562-1761065910=:4580"
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-670500562-1761065910=:4580
Content-Type: text/plain; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hi,

I have now read more thoroughly through the whole RFC, and I am less=20
happier with it than I was.

On Tue, 14 Oct 2025, Edmond Dantes wrote:

> On Tue, 14 Oct 20205, Larry Garfield wrote:
>
> > It's vastly improved from the first version back in the spring, but=20
> > there are still numerous footguns
>=20
> Which specific footguns? $scope var?

There are many as I see them, to name a few:

- A new ini setting =E2=80=94 we would be much better off picking a value, =
and=20
  stick with with it.
- Showing warnings when all sort of issues happen.
- Indeed, the passing around of "$scope".
- "A good practice is to ensure that a Scope object has only ONE owner."=20
  =E2=80=94 that really ought to be enforced
- "Passing $scope as a parameter to other functions or assigning it to mult=
iple
  objects is a potentially dangerous operation that can lead to complex bug=
s."
  =E2=80=94 so this isn't something a design should even allow.
- "Awaiting a Scope is a potentially dangerous operation that should be
  performed consciously, not accidentally. " =E2=80=94 a design should prev=
ent PHP
  users from making potentially dangerous situations.
- Disposing etc, I don't think I even understand what you're trying to do w=
ith
  this, considering warnings, zombies, etc.
- "Warning: You should not attempt to suppress CancellationError exception,=
 as
  it may cause application malfunctions." =E2=80=94 again, a good design sh=
ould not
  require our users to have to think of this.
- Hierarchies of scopes make for a lot of complexity. I doubt whether this =
is
  useful in most cases.

There is a lot of complexity and I still also think this RFC is trying to d=
o
way too much. PHP is *primarily* used as a web language, and the goal of ad=
ding
concurrency into it should make the live of web developers easier. This see=
ms
to be designed fo running PHP as a long time running script/event loop. We =
have
web servers and FrankenPHP for that.

In addition:

The RFC also doesn't describe how scheduling works. You call it "out of=20
scope", but as this is needed for this whole concept to work, it very=20
much ought to be in scope.

In the second example of "Coroutine::onFinally" there is an onFinally() cal=
l
without object.

Under "Tools", there is: "getSuspendFileAndLine():array =09Returns an array=
 of
two elements: the file name and the line number where the coroutine was las=
t
suspended. If the coroutine has not been suspended, it may return empty
string,0." Returning bogus values (empty string, and 0) isn't a good idea.
Instead, the method should probably have a "?array" return type.

"The format of this array depends on the implementation of the Scheduler an=
d
the Reactor." =E2=80=94 Spell out what these are, and how they're supposed =
to work. We
cannot make decisions on non-complete information.

"Therefore, using concurrency is reasonable only for long-life scenarios
implemented via CLI." =E2=80=94 I thought the whole point of this was so th=
at
developers can use concurrent things during their *web* requests =E2=80=94 =
for example
running several queries at the same time, or doing multiple http requests.
Isn't that what you would expect people to use concurrency for?

I don't understand why the "NGINX Unit integration example" is part of this=
 RFC.

> > I very much want to see it evolve further in that direction before a vo=
te
> > is called and we're locked into a system with so many foot guns built i=
n.
>=20
> Such an approach would require more changes to the code, and I don=E2=80=
=99t
> see how it would protect the programmer from mistakes any better than
> this RFC does.

In my opinion, it was not wise to spend so much time on the code (beyond
prototyping). The role of the RFC process is to hammer out a good feature f=
or
PHP, with the code being (mostly) an implementation detail.

> My position is this: **TrueAsync** should support the best patterns
> for specific use cases while still remaining convenient for the
> majority of tasks.

The "Goals" describe what you would like this feature to be, but not *why*.=
 The
RFC does not describe why this feature is important for PHP for specific us=
e
cases at all.

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-670500562-1761065910=:4580--