Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128853
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 16 Oct 2025 13:31:21 +0200
To: internals@lists.php.net
Message-ID: <436d4ede-c08e-4e7d-9ae2-8342f7f827ed@app.fastmail.com>
In-Reply-To: 
 <CAKXKfQtO+yoFB1=6zonwgGRpx1YExBNSkcjpso51aJ59YzaDLQ@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <bcd8253c-04f3-4046-b51f-2e387e215f6d@app.fastmail.com>
 <CAMW7n8BfP7h5rpDrjigu0oWK4Z+aRaqGjgzEFS_mDXRhq19vQQ@mail.gmail.com>
 <2b9fd3ec-50ca-41e4-985a-274f886df8b3@app.fastmail.com>
 <CAMW7n8C5GD+F2KdCZTtZwFbc2rk_4yGgdiak8fs9y5Z3UU_zxg@mail.gmail.com>
 <2e39e211-c816-41db-a079-f2c6b3934e0a@app.fastmail.com>
 <CAKXKfQtO+yoFB1=6zonwgGRpx1YExBNSkcjpso51aJ59YzaDLQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=8d407de2dabc43d4b3d5f6e0712d34a1
From: rob@bottled.codes ("Rob Landers")

--8d407de2dabc43d4b3d5f6e0712d34a1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Oct 16, 2025, at 09:38, Daniil Gentili wrote:
>=20
> > You've provided examples and said that it violates design and fundam=
ental elements, but not which design and fundamentals, ie, the evidence =
for the decision. I would expect more than "because I said so" for such =
a huge language feature, but rather arguments grounded in computer scien=
ce.=20
>=20
>=20
> He very explicitly described the issue, in objective terms: a breach o=
f agreement in the context of the invocation of a foreign interface.
>=20
> In simpler terms, you can't and should not be able to mess with the in=
ternals of code you didn't write: this is similar to the principle of en=
capsulation in OOP, where you cannot modify private properties of an obj=
ect.
>=20
>=20
> Cancellation should be part of the contract of an async function: it i=
s safe, and most async languages already implement it explicitly by pass=
ing a context or a cancellation token, the current approach of the RFC d=
oes it implicitly, which is also fine.
>=20
> Awaiting for the completion of spawned coroutines should *not* be part=
 of the contract of an async function: it is an incredibly easy footgun,=
 as it's incredibly easy to spawn a coroutine meant to i.e. run until th=
e object is destroyed, and then encounter a deadlock when the linked sco=
pe is awaited for before the object is destroyed (even messier if cycles=
 and thus the GC are involved).
>=20
> Languages like Kotlin that do implement await on scopes have already r=
ealized that it is a mistake, as can be seen by the many warnings agains=
t using await on a scope, as I already linked in previous emails.
>=20
> On the other hand, making the same mistake described above, by cancell=
ing a scope, will produce a very easy to debug exception instead of a de=
adlock, easily fixable by (warning the author of the library class) to u=
se a new scope to spawn coroutines within the object.
>=20
> Awaiting a scope leads to deadlocks in case where a separate scope is =
needed but not used, cancelling them leads to a simple exception.
> Awaiting on multiple tasks can already be done, explicitly, with TaskG=
roup.
>=20
>=20
> Regards,
> Daniil Gentili.

Hey Daniil and Edmond,

I think I understand the intention. Would it be better to instead of hav=
ing ->awaitCompletion (which feels like an implicit implementation of Aw=
aitable without an explicit implmentation -- which is the part that was =
bothering me), maybe having something like ->joinAll() or ->joinOnCancel=
lation()? That way someone like me won't come along and wrap them in an =
Awaitable because it looks Awaitable.

It also might be a good idea to make specifying a timeout in ms mandator=
y, instead of a taking an Awaitable/Cancellation. This would also preven=
t people from simply passing a "never returning" Awaitable thinking they=
're being clever.

It also might be good to provide a realistic looking example showing a "=
bad case" of how this is dangerous instead of simply saying that it is, =
showing how a scope is not a 'future', but a container, and preemptively=
 mention TaskGroups, linking to the future scope (which it should also p=
robably be listed there as well).

=E2=80=94 Rob
--8d407de2dabc43d4b3d5f6e0712d34a1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Thu, Oct 16, 2025, at 09:38, Daniil Gentili wrote:<=
/div><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"auto"><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">&gt; You've provided example=
s and said that it violates design and fundamental elements, but not whi=
ch design and fundamentals, ie, the evidence for the decision. I would e=
xpect more than "because I said so" for such a huge language feature, bu=
t rather arguments grounded in computer science.&nbsp;</div><div dir=3D"=
auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">He very ex=
plicitly described the issue, in objective terms: a breach of agreement =
in the context of the invocation of a foreign interface.</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">In simpler terms, you can't and shoul=
d not be able to mess with the internals of code you didn't write: this =
is similar to the principle of encapsulation in OOP, where you cannot mo=
dify private properties of an object.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Cancellation should be part=
 of the contract of an async function: it is safe, and most async langua=
ges already implement it explicitly by passing a context or a cancellati=
on token, the current approach of the RFC does it implicitly, which is a=
lso fine.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Awaiting fo=
r the completion of spawned coroutines should *not* be part of the contr=
act of an async function: it is an incredibly easy footgun, as it's incr=
edibly easy to spawn a coroutine meant to i.e. run until the object is d=
estroyed, and then encounter a deadlock when the linked scope is awaited=
 for before the object is destroyed (even messier if cycles and thus the=
 GC are involved).</div><div dir=3D"auto"><br></div><div dir=3D"auto"><s=
pan class=3D"size" style=3D"font-size:10pt;">Languages like Kotlin that =
do implement await on scopes have already realized that it is a mistake,=
 as can be seen by the many warnings against using await on a scope, as =
I already linked in previous emails.</span></div><div dir=3D"auto"><span=
 class=3D"size" style=3D"font-size:10pt;"></span><br></div><div dir=3D"a=
uto"><span class=3D"size" style=3D"font-size:10pt;">On the other hand, m=
aking the same mistake described above, by cancelling a scope, will prod=
uce a very easy to debug exception instead of a deadlock, easily fixable=
 by (warning the author of the library class) to use a new scope to spaw=
n&nbsp;</span><span class=3D"size" style=3D"font-size:10pt;">coroutines =
within the object.</span></div><div dir=3D"auto"><span class=3D"size" st=
yle=3D"font-size:10pt;"></span><br></div><div dir=3D"auto"><span class=3D=
"size" style=3D"font-size:10pt;">Awaiting a scope leads to deadlocks in =
case where a separate scope is needed but not used, cancelling them lead=
s to a simple exception.</span></div><div dir=3D"auto"><span class=3D"si=
ze" style=3D"font-size:10pt;">Awaiting on multiple tasks can already be =
done, explicitly, with TaskGroup.</span></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">Regards,</div><div dir=3D=
"auto">Daniil Gentili.</div></div></blockquote><div><br></div><div>Hey&n=
bsp;Daniil and Edmond,</div><div><br></div><div>I think I understand the=
 intention. Would it be better to instead of having -&gt;awaitCompletion=
 (which feels like an implicit implementation of Awaitable without an ex=
plicit implmentation -- which is the part that was bothering me), maybe =
having something like -&gt;joinAll() or -&gt;joinOnCancellation()? That =
way someone like me won't come along and wrap them in an Awaitable becau=
se it looks Awaitable.</div><div><br></div><div>It also might be a good =
idea to make specifying a timeout in ms mandatory, instead of a taking a=
n Awaitable/Cancellation. This would also prevent people from simply pas=
sing a "never returning" Awaitable thinking they're being clever.</div><=
div><br></div><div>It also might be good to provide a realistic looking =
example showing a "bad case" of how this is dangerous instead of simply =
saying that it is, showing how a scope is not a 'future', but a containe=
r, and preemptively mention TaskGroups, linking to the future scope (whi=
ch it should also probably be listed there as well).</div><div><br></div=
><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--8d407de2dabc43d4b3d5f6e0712d34a1--