Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128898
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>
In-Reply-To: <151800a7-1094-49bc-8e43-c593a74741af@app.fastmail.com>
Date: Wed, 22 Oct 2025 12:35:16 +0300
Message-ID: <CAMW7n8CWMpUmVB+FHjuYNFMzswbW5Lo19C1D6CTri6HVsddwkQ@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)

> The example I gave is probably a good one? If I'm writing framework-y cod=
e, 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 differe=
nt result every time? If I'm wrong, I could end up in an infinite loop, or =
missing results.
> Further, how do I know whether the last value from an Awaitable is the la=
st value? I think if you could illustrate that in the RFC or change the sem=
antics, that'd be fine.

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.

As for the infinite loop issue, the situation depends on the
termination conditions. For example:

```php

$queue =3D new Queue();

// Rust future-based
while(true) {
    $future =3D $queue->next();
    if($future =3D=3D=3D null) {
          break;
    }

    await($future);
}
```

or

```php
$queue =3D new Queue();

// Awaitable style
while($queue->isClosed() =3D=3D=3D false) {
    await($queue);
}

```

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.

> Accidentally sent too early: but also, what if there are multiple awaiter=
s for a non-idempotent Awaiter? How do we handle that?

All of this completely depends on the implementation of the awaited object.

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.

In Rust, it=E2=80=99s common practice to use methods that create a new Futu=
re
(or NULL) when a certain action needs to be awaited, like:

```rust
while let Some(v) =3D rx.recv().await {
    println!("Got: {}", v);
}
```

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...

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.

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. Wheth=
er
the last message is cached or not, and so on.

In summary, a programmer must understand what kind of object they=E2=80=99r=
e
actually working with. It=E2=80=99s unlikely that this can be avoided.