Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128878
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <0e4e39d6-9cc9-4970-92e0-2463143b4011@app.fastmail.com>
In-Reply-To: <0e4e39d6-9cc9-4970-92e0-2463143b4011@app.fastmail.com>
Date: Tue, 21 Oct 2025 16:33:21 +0300
Message-ID: <CAMW7n8DgjfEJJ6xoRA7Bs9-H9qZL=+o69QyXAVo=wSACug=e3w@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

> When I await(), do I need to do it in a loop, or just once?

It depends on what is being awaited.
On one hand, it would probably be convenient to have many different
operations for different cases, but then we make the language
semantics more complex.

> Coroutines become Future that only await once, while Signal is something =
that can be awaited many times.
At the moment, only such objects exist. It=E2=80=99s hard to say whether th=
ere
will be others.
Although one can imagine an Interval object, there are some doubts
about whether such an object should be used in a while await loop,
because from a performance standpoint, it=E2=80=99s not very efficient.

> But the example setChildScopeExceptionHandler does exactly this!
The Scope-level handler does not interfere with coroutine completion.
And it is not called because the cancellation exception is "absorbed"
by the coroutine.

> Further, much framework/app code uses the $previous to wrap exceptions as=
 they bubble up,

If a programmer wants to wrap an exception in their own one let them.
No one forbids catching exceptions; they just shouldn=E2=80=99t be suppress=
ed.

> Async\isCancellation(Throwable): bool
Why make a separate function if you can just walk through the chain?

> Minor nit: in the Async\protect section, it would be nice to say that can=
cellations being AFTER the protect() are guaranteed, and also specify reent=
ry/nesting of protect(). Like what happens here:

That=E2=80=99s a good case! Re-entering protect should be forbidden that mu=
st
not be allowed.

> Also, if I'm reading this correctly, a coroutine can mark itself as cance=
led, yet run to completion; however anyone await()'ing it, will get a Cance=
llationException instead of the completed value?
If a coroutine is canceled, its return value will be ignored.
However, of course, it can still call return, and that will work
without any issues.
I considered issuing a warning for such behavior but later removed it,
since I don=E2=80=99t see it as particularly dangerous.
This point requires attention, because there=E2=80=99s a certain =E2=80=9Cf=
lexibility=E2=80=9D
here that can be confusing. However, the risk in this case is low.

> Allowing destructors to spawn feels extremely dangerous to me (but powerf=
ul). These typically -- but not always -- run between the return statement =
and the next line (typically best to visualize that > as the "}" since it r=
uns in the original scope IIRC). That could make it 'feel like' methods/fun=
ctions are hanging or never returning if a library abuses this by suspendin=
g or awaiting something.

Launching coroutines in destructors is indeed a relatively dangerous
operation, but for different reasons mainly related to who owns such
coroutines. However, I didn=E2=80=99t quite understand what danger you were
referring to?

Asynchronous operations, as well as coroutine launching, are indeed
used in practice. The code executes properly, so I don=E2=80=99t quite see
what risks there could be, apart from potential resource leaks caused
by faulty coroutines.

> async.zombie_coroutine_timeout says 2 seconds in the text, but 5 seconds =
in the php.ini section.
Thanks.

> What is defined as "application considered finished?" FrankenPHP workers,=
 for instance, don=E2=80=99t "finish" =E2=80=94 is there a way to reap zomb=
ies manually?

The Scheduler keeps track of the number of coroutines being executed.
When the number of active coroutines reaches zero, the Scheduler stops
execution. Zombie coroutines are not counted among those that keep the
execution running. If PHP is running in worker mode, then the worker
code must correctly keep the execution active. But even workers
sometimes need to shutdown.

>  it would be good to specify ordering and finally/onFinally execution her=
e
Doesn=E2=80=99t the RFC define the order of onFinally handler execution?
onFinally handlers are executed after the coroutine or the Scope has comple=
ted.
onFinally is not directly related to dispose() in any way.

When dispose() is called, coroutine cancellation begins. This process
may take some time. Only after the last coroutine has stopped will
onFinally be invoked. In other words, you should not attempt to link
the calls of these methods in any way.

> Maybe something like Async\isEnabled() to know whether I should use fiber=
s or not.
Good idea!,
considering that such a function actually exists at the C code level.

> Is this "same exception" mean this literally, or is it a clone? If it is =
the same, what prevents another code path from mutating the original except=
ion before it gets to me?
It=E2=80=99s the exact same object that is, a reference to the same instanc=
e.
So if someone modifies it, those changes will, of course, take effect.

> Is there also a timeout on Phase 1 shutdown? Otherwise, if it is only an =
exception, then this could hang forever.

That=E2=80=99s true! A hang is indeed possible. I=E2=80=99m still not sure =
whether
it=E2=80=99s worth adding an auxiliary mechanism to handle such cases, beca=
use
that would effectively make PHP =E2=80=9Csmarter=E2=80=9D than the programm=
er. I
believe that a language should not try to be smarter than the
programmer if the application runs in a certain way, then it=E2=80=99s
probably meant to be that way.

> - Sometimes you use AwaitCancelledException and other times CancellationE=
rror. Which is it?
The old exception name apparently hasn=E2=80=99t been updated to the new on=
e everywhere.

> Nit: the error message has a grammatical error: "Cannot create a fiber wh=
ile an True Async is active" should be "Cannot create a fiber while True As=
ync is active"?
>
Thanks!