Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128899
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 22 Oct 2025 13:09:09 +0200
To: "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aaron Piotrowski" <aaron@trowski.com>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <c1f712d7-4922-4620-a1c6-e8fca72c9a55@app.fastmail.com>
In-Reply-To: 
 <CAMW7n8CWMpUmVB+FHjuYNFMzswbW5Lo19C1D6CTri6HVsddwkQ@mail.gmail.com>
References: 
 <CAMW7n8DGbFnQzjt3s9CcOBwhp+MUOV+K3U=yY=ULOTdUXaOLHQ@mail.gmail.com>
 <0e4e39d6-9cc9-4970-92e0-2463143b4011@app.fastmail.com>
 <CAMW7n8AgHnO0rBjqBkHNhfvV5PBNxwgHBJ762N3FtVxoh5WnOQ@mail.gmail.com>
 <E8D4A549-79EA-48E9-9D20-3608F357F227@trowski.com>
 <CAMW7n8D0wMNQE0zuMhbHstyZsDw=e7ryPPZERn11UFV7knmR-g@mail.gmail.com>
 <37180d8d-85b4-49a3-a672-334bf4329470@app.fastmail.com>
 <CAMW7n8AFaUByiJ=2frgkAFWNPWHS2wYyHiKfwf8dzT7AYnLjWg@mail.gmail.com>
 <2f8524a7-dea2-4fbf-933a-c538d3706253@app.fastmail.com>
 <CAMW7n8DKB+AWp2sWPi_w8ZgLQ_zS2MPNgP6n1G5127Nkk7EgOA@mail.gmail.com>
 <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com>
 <CAMW7n8CWMpUmVB+FHjuYNFMzswbW5Lo19C1D6CTri6HVsddwkQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=1dc8bed8be244005ad2b6b281ed99f10
From: rob@bottled.codes ("Rob Landers")

--1dc8bed8be244005ad2b6b281ed99f10
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, Oct 22, 2025, at 11:35, Edmond Dantes wrote:
> > The example I gave is probably a good one? If I'm writing framework-=
y code, how do I decide to await once, or in a loop? In other words,
> > how do I detect whether an Awaitable is idempotent or will give a di=
fferent result every time? If I'm wrong, I could end up in an infinite l=
oop, or missing results.
> > Further, how do I know whether the last value from an Awaitable is t=
he last value? I think if you could illustrate that in the RFC or change=
 the semantics, that'd be fine.
>=20
> If a function knows nothing about the object it=E2=80=99s awaiting, it=
=E2=80=99s
> equally helpless not only in deciding whether to use while or not, but
> also in determining how to handle the result.
>=20
> As for the infinite loop issue, the situation depends on the
> termination conditions. For example:
>=20
> ```php
>=20
> $queue =3D new Queue();
>=20
> // Rust future-based
> while(true) {
>     $future =3D $queue->next();
>     if($future =3D=3D=3D null) {
>           break;
>     }
>=20
>     await($future);
> }
> ```
>=20
> or
>=20
> ```php
> $queue =3D new Queue();
>=20
> // Awaitable style
> while($queue->isClosed() =3D=3D=3D false) {
>     await($queue);
> }
>=20
> ```
>=20
> In other words, a loop needs some method that limits its execution in
> any case and it=E2=80=99s hard to make a mistake with that.
>=20
> > Accidentally sent too early: but also, what if there are multiple aw=
aiters for a non-idempotent Awaiter? How do we handle that?
>=20
> All of this completely depends on the implementation of the awaited ob=
ject.
>=20
> The Awaitable contract does not define when the event will occur or
> whether it will be cached. it only guarantees that the object can be
> awaited.
> However, the exact moment when the object wakes the coroutine and what
> type of data it provides are all outside the scope of the awaiting
> contract.
>=20
> In Rust, it=E2=80=99s common practice to use methods that create a new=
 Future
> (or NULL) when a certain action needs to be awaited, like:
>=20
> ```rust
> while let Some(v) =3D rx.recv().await {
>     println!("Got: {}", v);
> }
> ```
>=20
> Multiple awaits usually appear as several different `Future` instances
> that can be created by the same awaitable object.
> However, the Rust approach doesn=E2=80=99t fundamentally change...
>=20
> If the internal logic of an Awaitable object loses an event before a
> Future is created, the behavior is effectively the same as if the
> Future never existed.
>=20
> The advantage of the Rust approach is that the programmer can clearly
> see that a Future is being created (rx.recv() should return Future new
> one or the same?). (Perhaps the code looks more compact)
> But they still have to read the documentation to understand how this
> Future completes, how it=E2=80=99s created, and what data it returns. =
Whether
> the last message is cached or not, and so on.
>=20
> In summary, a programmer must understand what kind of object they=E2=80=
=99re
> actually working with. It=E2=80=99s unlikely that this can be avoided.
>=20

I think that might make sense for Rust/Go which generally don't rely hea=
vily on frameworks, unlike PHP -- frameworks work from abstractions not =
concrete types. After some thinking about it the last day or so, here's =
the problems with the "multi-shot" vs. "single-shot" Awaitables:

1. refactoring hazards

If you await a value, everything works, but then someone somewhere else =
awaits the same Awaitable that wasn't actually a "one-shot" Awaitable, s=
o now everything breaks sometimes, and other times not -- depending on w=
hich one awaits first.

2. memoization becomes an issue

function getOnce(Awaitable $response) {
  static $cache =3D [];
  $id =3D spl_object_id($response);
  return $cache[$id] ??=3D await($response);
}

With a "multi-shot" Awaitable, this is not practical or even a good idea=
. You can't write general-purpose helpers, at all.

3. static analysis

psalm/phpstan can't warn you that you are dealing with a "multi-shot" or=
 "single-shot" Awaitable. The safest thing is to treat everything as "mu=
lti-shot" so you don't shoot yourself in the foot -- but there's no way =
to tell if you are intentionally getting the same object every time or i=
t is a "single-shot" Awaitable.

4. violation of algebraic laws with awaitAll/awaitAny

With "multi-shot" awaitables, awaitAll() becomes an infinite loop and do=
es awaitAny() does/doesn't guarantee idempotency.

5. violation of own invariants in the RFC

The RFC says that await will throw the SAME instance of exceptions, but =
with "multi-shot" Awaitables, will this in fact be the case? Could it th=
row an exception the first time but a result the next? Or maybe even dif=
ferent exceptions every time?

6. common patterns aren't guaranteed anymore

A common case is to "peek then act" on a value, so now this would be a v=
ery subtle footgun:

if (await($response)) {
  return await($response);
}

This is a pretty common pattern in TypeScript/JavaScript, where you don'=
t want to go through the effort of keeping a variable that may not even =
be acted on. Not to mention, many codestyles outlaw the following (putti=
ng assignment in if-statements):

if ($val =3D await($response)) {
  return $val;
}

7. retries are broken

I can imagine something like this being in frameworks:

retry:
try {
  return await($response, timeout(10));
} catch(CancellationException) {
  logSomething() // for a few ms while we continue to wait
  goto retry;
}

8. select/case doesn't require multishot

I'm not sure what you mean by this. In Go, you await a channel, who's va=
lue is single-shot. In C#, you await an IEnumerable which return Tasks, =
which the value is single-shot. In kotlin, you receive via deferred, who=
se value is single-shot.

So, in other words, maybe the queue/stream/whatever is multi-shot, but t=
he thing you pass to select() is single-shot.

9. how will the scheduler handle backpressure?

I think you mentioned elsewhere that the scheduler is currently relative=
ly rudimentary. From working on custom C# Task schedulers in the past, h=
aving multi-shot Awaitables will be terrible for scheduling. You'll have=
 no way to handle backpressure and ensure fairness.

I'm not sure what your thought process is here, because in the last few =
emails you've gone from "maybe" to doubling-down on this (from my perspe=
ctive), but I feel like this will be a footgun to both developers and th=
e future of the language.

=E2=80=94 Rob
--1dc8bed8be244005ad2b6b281ed99f10
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 Wed, Oct 22, 2025, at 11:35, Edmond Dantes wrote:</=
div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt; The example=
 I gave is probably a good one? If I'm writing framework-y code, how do =
I decide to await once, or in a loop? In other words,</div><div>&gt; how=
 do I detect whether an Awaitable is idempotent or will give a different=
 result every time? If I'm wrong, I could end up in an infinite loop, or=
 missing results.</div><div>&gt; Further, how do I know whether the last=
 value from an Awaitable is the last value? I think if you could illustr=
ate that in the RFC or change the semantics, that'd be fine.</div><div><=
br></div><div>If a function knows nothing about the object it=E2=80=99s =
awaiting, it=E2=80=99s</div><div>equally helpless not only in deciding w=
hether to use while or not, but</div><div>also in determining how to han=
dle the result.</div><div><br></div><div>As for the infinite loop issue,=
 the situation depends on the</div><div>termination conditions. For exam=
ple:</div><div><br></div><div>```php</div><div><br></div><div>$queue =3D=
 new Queue();</div><div><br></div><div>// Rust future-based</div><div>wh=
ile(true) {</div><div>&nbsp;&nbsp;&nbsp; $future =3D $queue-&gt;next();<=
/div><div>&nbsp;&nbsp;&nbsp; if($future =3D=3D=3D null) {</div><div>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; break;</div><div>&nbs=
p;&nbsp;&nbsp; }</div><div><br></div><div>&nbsp;&nbsp;&nbsp; await($futu=
re);</div><div>}</div><div>```</div><div><br></div><div>or</div><div><br=
></div><div>```php</div><div>$queue =3D new Queue();</div><div><br></div=
><div>// Awaitable style</div><div>while($queue-&gt;isClosed() =3D=3D=3D=
 false) {</div><div>&nbsp;&nbsp;&nbsp; await($queue);</div><div>}</div><=
div><br></div><div>```</div><div><br></div><div>In other words, a loop n=
eeds some method that limits its execution in</div><div>any case and it=E2=
=80=99s hard to make a mistake with that.</div><div><br></div><div>&gt; =
Accidentally sent too early: but also, what if there are multiple awaite=
rs for a non-idempotent Awaiter? How do we handle that?</div><div><br></=
div><div>All of this completely depends on the implementation of the awa=
ited object.</div><div><br></div><div>The Awaitable contract does not de=
fine when the event will occur or</div><div>whether it will be cached. i=
t only guarantees that the object can be</div><div>awaited.</div><div>Ho=
wever, the exact moment when the object wakes the coroutine and what</di=
v><div>type of data it provides are all outside the scope of the awaitin=
g</div><div>contract.</div><div><br></div><div>In Rust, it=E2=80=99s com=
mon practice to use methods that create a new Future</div><div>(or NULL)=
 when a certain action needs to be awaited, like:</div><div><br></div><d=
iv>```rust</div><div>while let Some(v) =3D&nbsp;<a href=3D"http://rx.rec=
v">rx.recv</a>().await {</div><div>&nbsp;&nbsp;&nbsp; println!("Got: {}"=
, v);</div><div>}</div><div>```</div><div><br></div><div>Multiple awaits=
 usually appear as several different `Future` instances</div><div>that c=
an be created by the same awaitable object.</div><div>However, the Rust =
approach doesn=E2=80=99t fundamentally change...</div><div><br></div><di=
v>If the internal logic of an Awaitable object loses an event before a</=
div><div>Future is created, the behavior is effectively the same as if t=
he</div><div>Future never existed.</div><div><br></div><div>The advantag=
e of the Rust approach is that the programmer can clearly</div><div>see =
that a Future is being created (<a href=3D"http://rx.recv">rx.recv</a>()=
 should return Future new</div><div>one or the same?). (Perhaps the code=
 looks more compact)</div><div>But they still have to read the documenta=
tion to understand how this</div><div>Future completes, how it=E2=80=99s=
 created, and what data it returns. Whether</div><div>the last message i=
s cached or not, and so on.</div><div><br></div><div>In summary, a progr=
ammer must understand what kind of object they=E2=80=99re</div><div>actu=
ally working with. It=E2=80=99s unlikely that this can be avoided.</div>=
<div><br></div></blockquote><div><br></div><div>I think that might make =
sense for Rust/Go which generally don't rely heavily on frameworks, unli=
ke PHP -- frameworks work from abstractions not concrete types. After so=
me thinking about it the last day or so, here's the problems with the "m=
ulti-shot" vs. "single-shot" Awaitables:</div><div><br></div><div>1. ref=
actoring hazards</div><div><br></div><div>If you await a value, everythi=
ng works, but then someone somewhere else awaits the same Awaitable that=
 wasn't actually a "one-shot" Awaitable, so now everything breaks someti=
mes, and other times not -- depending on which one awaits first.</div><d=
iv><br></div><div>2. memoization becomes an issue</div><div><br></div><d=
iv>function getOnce(Awaitable $response) {</div><div>&nbsp; static $cach=
e =3D [];</div><div>&nbsp; $id =3D spl_object_id($response);</div><div>&=
nbsp; return $cache[$id] ??=3D await($response);</div><div>}</div><div><=
br></div><div>With a "multi-shot" Awaitable, this is not practical or ev=
en a good idea. You can't write general-purpose helpers, at all.</div><d=
iv><br></div><div>3. static analysis</div><div><br></div><div>psalm/phps=
tan can't warn you that you are dealing with a "multi-shot" or "single-s=
hot" Awaitable. The safest thing is to treat everything as "multi-shot" =
so you don't shoot yourself in the foot -- but there's no way to tell if=
 you are intentionally getting the same object every time or it is a "si=
ngle-shot" Awaitable.</div><div><br></div><div>4. violation of algebraic=
 laws with awaitAll/awaitAny</div><div><br></div><div>With "multi-shot" =
awaitables, awaitAll() becomes an infinite loop and does awaitAny() does=
/doesn't guarantee idempotency.</div><div><br></div><div>5. violation of=
 own invariants in the RFC</div><div><br></div><div>The RFC says that aw=
ait will throw the SAME instance of exceptions, but with "multi-shot" Aw=
aitables, will this in fact be the case? Could it throw an exception the=
 first time but a result the next? Or maybe even different exceptions ev=
ery time?</div><div><br></div><div>6. common patterns aren't guaranteed =
anymore</div><div><br></div><div>A common case is to "peek then act" on =
a value, so now this would be a very subtle footgun:</div><div><br></div=
><div>if (await($response)) {</div><div>&nbsp; return await($response);<=
/div><div>}</div><div><br></div><div>This is a pretty common pattern in =
TypeScript/JavaScript, where you don't want to go through the effort of =
keeping a variable that may not even be acted on. Not to mention, many c=
odestyles outlaw the following (putting assignment in if-statements):</d=
iv><div><br></div><div>if ($val =3D await($response)) {</div><div>&nbsp;=
 return $val;</div><div>}</div><div><br></div><div>7. retries are broken=
</div><div><br></div><div>I can imagine something like this being in fra=
meworks:</div><div><br></div><div>retry:</div><div>try {</div><div>&nbsp=
; return await($response, timeout(10));</div><div>} catch(CancellationEx=
ception) {</div><div>&nbsp; logSomething() // for a few ms while we cont=
inue to wait</div><div>&nbsp; goto retry;</div><div>}</div><div><br></di=
v><div>8. select/case doesn't require multishot</div><div><br></div><div=
>I'm not sure what you mean by this. In Go, you await a channel, who's v=
alue is single-shot. In C#, you await an IEnumerable which return Tasks,=
 which the value is single-shot. In kotlin, you receive via deferred, wh=
ose value is single-shot.</div><div><br></div><div>So, in other words, m=
aybe the queue/stream/whatever is multi-shot, but the thing you pass to =
select() is single-shot.</div><div><br></div><div>9. how will the schedu=
ler handle backpressure?</div><div><br></div><div>I think you mentioned =
elsewhere that the scheduler is currently relatively rudimentary. From w=
orking on custom C# Task schedulers in the past, having multi-shot Await=
ables will be terrible for scheduling. You'll have no way to handle back=
pressure and ensure fairness.</div><div><br></div><div>I'm not sure what=
 your thought process is here, because in the last few emails you've gon=
e from "maybe" to doubling-down on this (from my perspective), but I fee=
l like this will be a footgun to both developers and the future of the l=
anguage.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div=
></body></html>
--1dc8bed8be244005ad2b6b281ed99f10--