Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128882
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 21 Oct 2025 17:02:51 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: internals@lists.php.net
Message-ID: <ce95cee2-32b3-4dbb-93b0-494cf05260b5@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8DgjfEJJ6xoRA7Bs9-H9qZL=+o69QyXAVo=wSACug=e3w@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <0e4e39d6-9cc9-4970-92e0-2463143b4011@app.fastmail.com>
 <CAMW7n8DgjfEJJ6xoRA7Bs9-H9qZL=+o69QyXAVo=wSACug=e3w@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=a17ed135aa9449019bed667909b4e0cf
From: rob@bottled.codes ("Rob Landers")

--a17ed135aa9449019bed667909b4e0cf
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 21, 2025, at 15:33, Edmond Dantes wrote:
> > When I await(), do I need to do it in a loop, or just once?
>=20
> 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 somet=
hing that can be awaited many times.
> At the moment, only such objects exist. It=E2=80=99s hard to say wheth=
er there
> 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.

It might be good to clarify this when we talk about the Awaitable Interf=
ace then? Maybe something like:

"In PHP 8.6 the only awaitables are single-completion. Future versions m=
ay add multi-event awaitables." just to clear it up for early adopters?

> > 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.

:thumbsup:

> > Further, much framework/app code uses the $previous to wrap exceptio=
ns as they bubble up,
>=20
> 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 sup=
pressed.

>=20
> > Async\isCancellation(Throwable): bool
> Why make a separate function if you can just walk through the chain?

If everyone writes their own isCancellation() we risk divergence (not to=
 mention, it will be faster in C and basically need to be checked on eve=
ry catch that might await); having one blessed function guarantees consi=
stent detection and can allow for static-analysis support.

>=20
> > Minor nit: in the Async\protect section, it would be nice to say tha=
t cancellations being AFTER the protect() are guaranteed, and also speci=
fy reentry/nesting of protect(). Like what happens here:
>=20
> That=E2=80=99s a good case! Re-entering protect should be forbidden th=
at must
> not be allowed.

<3 that's good to know! It definately needs to be in the RFC. If you don=
't mind me asking: why is this the case?

>=20
> > Also, if I'm reading this correctly, a coroutine can mark itself as =
canceled, yet run to completion; however anyone await()'ing it, will get=
 a CancellationException 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=
=9Cflexibility=E2=80=9D
> here that can be confusing. However, the risk in this case is low.

I would find it surprising behaviour -- if you cancel a context in go, i=
t may or may not complete, but you get back both the completion (if it c=
ompleted) and/or the error. In C#, it throws an exception and it never c=
ompletes. Languages have different ways to do it, but it should be docum=
ented in the RFC what the behaviour is and how to handle this case. Ergo=
nomics matter as much as the feature existing.

As far as observability goes, it might be a good idea to issue a notice =
instead of a warning. Notice is often suppressed and rarely causes any i=
ssues, but in development, seeing that would at least let me know someth=
ing was going on that I should investigate.

>=20
> > Allowing destructors to spawn feels extremely dangerous to me (but p=
owerful). These typically -- but not always -- run between the return st=
atement and the next line (typically best to visualize that > as the "}"=
 since it runs in the original scope IIRC). That could make it 'feel lik=
e' methods/functions are hanging or never returning if a library abuses =
this by suspending or awaiting something.
>=20
> 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?
>=20
> 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.

I think we missed each other here. Consider the following code:

function test() {
    $r =3D new AsyncResource();
    return 42; // destructor suspends here
}

Would this delay the caller's return until the destructor's coroutine fi=
nished, or is it detached? If detached, can it interleave safely with su=
bsequent code? This should be documented in the RFC so people can plan f=
or it and use it appropriately (such as managing transactions or locks i=
nside destructors).

> > async.zombie_coroutine_timeout says 2 seconds in the text, but 5 sec=
onds in the php.ini section.
> Thanks.
>=20
> > What is defined as "application considered finished?" FrankenPHP wor=
kers, for instance, don=E2=80=99t "finish" =E2=80=94 is there a way to r=
eap zombies manually?
>=20
> 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.

I have some workers that haven't restarted since April. :) So, having a =
way to manually reap zombies (much like we do with OS-level code when ru=
nning as PID 1) and track them, would be nice to have. At least, as part=
 of the scheduler API.

>=20
> >  it would be good to specify ordering and finally/onFinally executio=
n here
> Doesn=E2=80=99t the RFC define the order of onFinally handler executio=
n?
> onFinally handlers are executed after the coroutine or the Scope has c=
ompleted.
> onFinally is not directly related to dispose() in any way.
>=20
> 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.

This should be documented on the RFC, it still doesn't explain what the =
order of operations is though. This matters because if you are doing cle=
anup during disposal, you need to know what things will still be around =
(for reference, order of operations for GC is well documented and define=
d https://www.php.net/manual/en/features.gc.collecting-cycles.php which =
is what I'm expecting to see here).

>=20
> > Maybe something like Async\isEnabled() to know whether I should use =
fibers or not.
> Good idea!,
> considering that such a function actually exists at the C code level.
>=20
> > Is this "same exception" mean this literally, or is it a clone? If i=
t is the same, what prevents another code path from mutating the origina=
l exception before it gets to me?
> It=E2=80=99s the exact same object that is, a reference to the same in=
stance.
> So if someone modifies it, those changes will, of course, take effect.

This should probably be documented in the RFC: "Exceptions and returned =
objects are shared objects; mutating them is undefined behavior if there=
 are multiple awaiters."

>=20
> > Is there also a timeout on Phase 1 shutdown? Otherwise, if it is onl=
y an exception, then this could hang forever.
>=20
> 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,=
 because
> that would effectively make PHP =E2=80=9Csmarter=E2=80=9D than the pro=
grammer. 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.

I think of it more as observability than smarts (esp if the timeout is c=
onfigurable) ... otherwise, how would you even know if it is hanging on =
shutdown vs. doesn't even know it is supposed to be shutting down? I'm r=
eminded of certain CLI tools that require me issuing a SIGTSTP (ctrl-z) =
to issue a SIGTERM or SIGKILL because SIGINT (ctrl-c) doesn't appear to =
work. If it is my program, is it that there is a bug with SIGINT handler=
s -- or is it hanging during shutdown? Having a timeout there would at l=
east protect me from my customers/users getting stuck due to a bug, and =
I could always set the timeout to something infinite-ish (0? -1?) if tha=
t is the behaviour I want.

=E2=80=94 Rob
--a17ed135aa9449019bed667909b4e0cf
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Tue, Oct =
21, 2025, at 15:33, Edmond Dantes wrote:</div><blockquote type=3D"cite" =
id=3D"qt" style=3D""><div>&gt; When I await(), do I need to do it in a l=
oop, or just once?</div><div><br></div><div>It depends on what is being =
awaited.</div><div>On one hand, it would probably be convenient to have =
many different</div><div>operations for different cases, but then we mak=
e the language</div><div>semantics more complex.<br></div></blockquote><=
div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt; C=
oroutines become Future that only await once, while Signal is something =
that can be awaited many times.</div><div>At the moment, only such objec=
ts exist. It=E2=80=99s hard to say whether there</div><div>will be other=
s.</div><div>Although one can imagine an Interval object, there are some=
 doubts</div><div>about whether such an object should be used in a while=
 await loop,</div><div>because from a performance standpoint, it=E2=80=99=
s not very efficient.</div></blockquote><div><br></div><div>It might be =
good to clarify this when we talk about the Awaitable Interface then? Ma=
ybe something like:</div><div><br></div><div>"In PHP 8.6 the only awaita=
bles are single-completion. Future versions may add multi-event awaitabl=
es." just to clear it up for early adopters?<br></div><div><br></div><bl=
ockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt; But the example se=
tChildScopeExceptionHandler does exactly this!</div><div>The Scope-level=
 handler does not interfere with coroutine completion.</div><div>And it =
is not called because the cancellation exception is "absorbed"</div><div=
>by the coroutine.</div></blockquote><div><br></div><div>:thumbsup:</div=
><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt;=
 Further, much framework/app code uses the $previous to wrap exceptions =
as they bubble up,</div><div><br></div><div>If a programmer wants to wra=
p an exception in their own one let them.</div><div>No one forbids catch=
ing exceptions; they just shouldn=E2=80=99t be suppressed.<br></div></bl=
ockquote><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><=
div><br></div><div>&gt; Async\isCancellation(Throwable): bool</div><div>=
Why make a separate function if you can just walk through the chain?</di=
v></blockquote><div><br></div><div>If everyone writes their own isCancel=
lation() we risk divergence (not to mention, it will be faster in C and =
basically need to be checked on every catch that might await); having on=
e blessed function guarantees consistent detection and can allow for sta=
tic-analysis support.</div><div><br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div><br></div><div>&gt; Minor nit: in the Async\protect=
 section, it would be nice to say that cancellations being AFTER the pro=
tect() are guaranteed, and also specify reentry/nesting of protect(). Li=
ke what happens here:</div><div><br></div><div>That=E2=80=99s a good cas=
e! Re-entering protect should be forbidden that must</div><div>not be al=
lowed.</div></blockquote><div><br></div><div>&lt;3 that's good to know! =
It definately needs to be in the RFC. If you don't mind me asking: why i=
s this the case?</div><div><br></div><blockquote type=3D"cite" id=3D"qt"=
 style=3D""><div><br></div><div>&gt; Also, if I'm reading this correctly=
, a coroutine can mark itself as canceled, yet run to completion; howeve=
r anyone await()'ing it, will get a CancellationException instead of the=
 completed value?</div><div>If a coroutine is canceled, its return value=
 will be ignored.</div><div>However, of course, it can still call return=
, and that will work</div><div>without any issues.</div><div>I considere=
d issuing a warning for such behavior but later removed it,</div><div>si=
nce I don=E2=80=99t see it as particularly dangerous.</div><div>This poi=
nt requires attention, because there=E2=80=99s a certain =E2=80=9Cflexib=
ility=E2=80=9D</div><div>here that can be confusing. However, the risk i=
n this case is low.</div></blockquote><div><br></div><div>I would find i=
t surprising behaviour -- if you cancel a context in go, it may or may n=
ot complete, but you get back both the completion (if it completed) and/=
or the error. In C#, it throws an exception and it never completes. Lang=
uages have different ways to do it, but it should be documented in the R=
FC what the behaviour is and how to handle this case. Ergonomics matter =
as much as the feature existing.</div><div><br></div><div>As far as obse=
rvability goes, it might be a good idea to issue a notice instead of a w=
arning. Notice is often suppressed and rarely causes any issues, but in =
development, seeing that would at least let me know something was going =
on that I should investigate.</div><div><br></div><blockquote type=3D"ci=
te" id=3D"qt" style=3D""><div><br></div><div>&gt; Allowing destructors t=
o spawn feels extremely dangerous to me (but powerful). These typically =
-- but not always -- run between the return statement and the next line =
(typically best to visualize that &gt; as the "}" since it runs in the o=
riginal scope IIRC). That could make it 'feel like' methods/functions ar=
e hanging or never returning if a library abuses this by suspending or a=
waiting something.</div><div><br></div><div>Launching coroutines in dest=
ructors is indeed a relatively dangerous</div><div>operation, but for di=
fferent reasons mainly related to who owns such</div><div>coroutines. Ho=
wever, I didn=E2=80=99t quite understand what danger you were</div><div>=
referring to?</div><div><br></div><div>Asynchronous operations, as well =
as coroutine launching, are indeed</div><div>used in practice. The code =
executes properly, so I don=E2=80=99t quite see</div><div>what risks the=
re could be, apart from potential resource leaks caused</div><div>by fau=
lty coroutines.</div></blockquote><div><br></div><div>I think we missed =
each other here. Consider the following code:</div><div><br></div><div>f=
unction test() {<br></div><div>&nbsp; &nbsp; $r =3D new AsyncResource();=
<br></div><div>&nbsp; &nbsp; return 42; // destructor suspends here<br><=
/div><div>}</div><div><br></div><div>Would this delay the caller's retur=
n until the destructor's coroutine finished, or is it detached? If detac=
hed, can it interleave safely with subsequent code? This should be docum=
ented in the RFC so people can plan for it and use it appropriately (suc=
h as managing transactions or locks inside destructors).<br></div><div><=
br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt;&nbsp;<=
a href=3D"http://async.zombie">async.zombie</a>_coroutine_timeout says 2=
 seconds in the text, but 5 seconds in the&nbsp;<a href=3D"http://php.in=
i">php.ini</a> section.</div><div>Thanks.</div><div><br></div><div>&gt; =
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 =
zombies manually?</div><div><br></div><div>The Scheduler keeps track of =
the number of coroutines being executed.</div><div>When the number of ac=
tive coroutines reaches zero, the Scheduler stops</div><div>execution. Z=
ombie coroutines are not counted among those that keep the</div><div>exe=
cution running. If PHP is running in worker mode, then the worker</div><=
div>code must correctly keep the execution active. But even workers</div=
><div>sometimes need to shutdown.</div></blockquote><div><br></div><div>=
I have some workers that haven't restarted since April. :) So, having a =
way to manually reap zombies (much like we do with OS-level code when ru=
nning as PID 1) and track them, would be nice to have. At least, as part=
 of the scheduler API.</div><div><br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div><br></div><div>&gt;&nbsp; it would be good to speci=
fy ordering and finally/onFinally execution here</div><div>Doesn=E2=80=99=
t the RFC define the order of onFinally handler execution?</div><div>onF=
inally handlers are executed after the coroutine or the Scope has comple=
ted.</div><div>onFinally is not directly related to dispose() in any way=
.</div><div><br></div><div>When dispose() is called, coroutine cancellat=
ion begins. This process</div><div>may take some time. Only after the la=
st coroutine has stopped will</div><div>onFinally be invoked. In other w=
ords, you should not attempt to link</div><div>the calls of these method=
s in any way.</div></blockquote><div><br></div><div>This should be docum=
ented on the RFC, it still doesn't explain what the order of operations =
is though. This matters because if you are doing cleanup during disposal=
, you need to know what things will still be around (for reference,&nbsp=
;order of operations for GC is well documented and defined <a href=3D"ht=
tps://www.php.net/manual/en/features.gc.collecting-cycles.php">https://w=
ww.php.net/manual/en/features.gc.collecting-cycles.php</a>&nbsp;which is=
 what I'm expecting to see here).</div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div>&gt; Maybe something lik=
e Async\isEnabled() to know whether I should use fibers or not.</div><di=
v>Good idea!,</div><div>considering that such a function actually exists=
 at the C code level.</div><div><br></div><div>&gt; Is this "same except=
ion" mean this literally, or is it a clone? If it is the same, what prev=
ents another code path from mutating the original exception before it ge=
ts to me?</div><div>It=E2=80=99s the exact same object that is, a refere=
nce to the same instance.</div><div>So if someone modifies it, those cha=
nges will, of course, take effect.</div></blockquote><div><br></div><div=
>This should probably be documented in the RFC: "Exceptions and returned=
 objects are shared objects; mutating them is undefined behavior if ther=
e are multiple awaiters."<br></div><div><br></div><blockquote type=3D"ci=
te" id=3D"qt" style=3D""><div><br></div><div>&gt; Is there also a timeou=
t on Phase 1 shutdown? Otherwise, if it is only an exception, then this =
could hang forever.</div><div><br></div><div>That=E2=80=99s true! A hang=
 is indeed possible. I=E2=80=99m still not sure whether</div><div>it=E2=80=
=99s worth adding an auxiliary mechanism to handle such cases, because</=
div><div>that would effectively make PHP =E2=80=9Csmarter=E2=80=9D than =
the programmer. I</div><div>believe that a language should not try to be=
 smarter than the</div><div>programmer if the application runs in a cert=
ain way, then it=E2=80=99s</div><div>probably meant to be that way.</div=
></blockquote><div><br></div><div>I think of it more as observability th=
an smarts (esp if the timeout is configurable) ... otherwise, how would =
you even know if it is hanging on shutdown vs. doesn't even know it is s=
upposed to be shutting down? I'm reminded of certain CLI tools that requ=
ire me issuing a SIGTSTP (ctrl-z) to issue a SIGTERM or SIGKILL because =
SIGINT (ctrl-c) doesn't appear to work. If it is my program, is it that =
there is a bug with SIGINT handlers -- or is it hanging during shutdown?=
 Having a timeout there would at least protect me from my customers/user=
s getting stuck due to a bug, and I could always set the timeout to some=
thing infinite-ish (0? -1?) if that is the behaviour I want.<br></div><d=
iv><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--a17ed135aa9449019bed667909b4e0cf--