Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128904
Precedence: list
MIME-Version: 1.0
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>
 <c1f712d7-4922-4620-a1c6-e8fca72c9a55@app.fastmail.com> <CAMW7n8Ah3LZDqV1eNoM45GWR2yOVLZxR58YuszbSNi34PMA4gw@mail.gmail.com>
 <772a457f-69b6-4a76-8224-081917d719f6@app.fastmail.com>
In-Reply-To: <772a457f-69b6-4a76-8224-081917d719f6@app.fastmail.com>
Date: Wed, 22 Oct 2025 18:30:09 +0300
Message-ID: <CAMW7n8C0BALniMyfCHfgC9qwS41jMZoM0a0u-vyBCjJY=fanLA@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
To: Rob Landers <rob@bottled.codes>
Cc: Aaron Piotrowski <aaron@trowski.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

> This isn't even the same example. We're not talking about type juggling, =
but an interface. Mixed is not an object nor an interface.
Why?
Type and Interface are contracts.

> The "FutureLike" type is exactly what I'm arguing for!

I have nothing against this interface. My point is different:
1. Should the await and awaitXX functions accept only Future?
2. Should Awaitable be hidden from the PHP userland?

> foreach($next =3D await($awaitable)) { }
What=E2=80=99s the problem here? The object will return a result.
If the result is iterable, it will go into the foreach loop. An
absolutely normal situation.

> error: multiple usages of multi-shot Awaitable; you may get a different r=
esult on each invocation of await()
Why can=E2=80=99t you call await twice? What=E2=80=99s illegal about it?
If it=E2=80=99s a Future, you=E2=80=99ll get the previous result; if it=E2=
=80=99s an
Awaitable, you=E2=80=99ll get the second value.
But the correctness of the code here 100% depends on the programmer=E2=80=
=99s intent.

> The RFC doesn't spell this out and needs some work here.
I don=E2=80=99t understand what exactly isn=E2=80=99t specified in the RFC?

> When I say "violations" I mean that, assuming $a and $b resolve instantly=
:
> awaitAll([$a, $b]) !=3D=3D [await($a), await($b)]
> ...

This is a logical error. =D0=A1ircular reasoning. The desired behavior is
being used here as proof of the undesired one. (recursion)
In the general case, these equations should not work =E2=80=94 and that=E2=
=80=99s
normal if the code expects entities that are not Future, but, for
example, channels.

> This is my mistake though. The discussion about await() is all mixed up w=
ith coroutines so its hard to tell what the actual behaviour for await() is=
 outside of the context of coroutines.
> The violation I thought of only applies to coroutines, the actual behavio=
ur is "undefined" in the RFC.

`await()` does two things:
1. Puts the coroutine into a waiting state.
2. Wakes it up when the `Awaitable` object emits an event.

`awaitAny` / `awaitAll` do the same but for a list of objects or an iterato=
r.

However, the result of `await()` depends on the object being awaited.
Thus, there are two separate contracts here:
1. **The waiting contract** =E2=80=94 how the waiting occurs.
2. **The result contract** =E2=80=94 how the result is obtained.

From a language design perspective, there should be an explicit
representation for these contracts.
Something similar appeared only in Swift (e.g., `try await`).

So, from the standpoint of =E2=80=9Cperfect design,=E2=80=9D this is a simp=
lification,
which makes it not ideal.

I can remove the `Awaitable` interface from the `RFC` and replace it
with `FutureLike`. It costs nothing to do so.
But before doing that, I want to be at least 95% sure that in 2=E2=80=933
years we won=E2=80=99t have to bring it back or add workarounds.

> It has everything to do with it! If a multi-shot Awaitable keeps emitting=
, this causes repeated wakeups to the same continuation. It has to schedule=
 this every time and there isn't a way to say "don't > produce until consum=
ed". You can basically starve other tasks from executing. However, if you u=
se iterables of single-shot Awaitables, you get backpressure "for free" and=
 don't request the next
> future until the previous one is complete, otherwise, the buffering press=
ure lands in the awaitable (unbounded memory) or in the schedulers ready qu=
eue (which affects fairness). Further, when
> cancelling a multi-shot awaitable, should the scheduler drop pending emis=
sions and what happens if it keeps re-enqueing it anyway? It makes the sche=
duler far more complicated than it needs to > be!

If an Awaitable object isn=E2=80=99t being awaited, it can=E2=80=99t emit e=
vents, nor
can it interfere with the scheduler.
Unless the programmer explicitly creates new coroutines for every event by =
hand.
If an Awaitable has a lot of data and wakes up 1000 coroutines, then
the scheduler will ensure that all those coroutines get executed.
But until these 1000 coroutines finish processing the data, the
Awaitable cannot wake anyone else.
So there is a natural limit to the number of subscribers. it can only
be exceeded through explicitly incorrect handling of coroutines.

Because the scheduler=E2=80=99s algorithm is extremely simple, it has littl=
e
to no starvation issues.
Starvation problems usually arise in schedulers that use more
=E2=80=9Cintelligent=E2=80=9D approaches.

> A footgun is any reasonable looking code that subtly breaks because the c=
ontract is weak, not because the programmer didn't RTFM.
The code cannot be considered =E2=80=9Creasonable,=E2=80=9D because in this=
 case the
programmer is clearly violating the contract.
And not because the contract is complex or confusing, but because they
completely ignored it. This doesn=E2=80=99t look like a footgun.