Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129007
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CADK1yXLLn1Sjp2ByxSJWBFhh+3dkTuFPtF7Cxrwz8TMzAZ-MZA@mail.gmail.com>
In-Reply-To: <CADK1yXLLn1Sjp2ByxSJWBFhh+3dkTuFPtF7Cxrwz8TMzAZ-MZA@mail.gmail.com>
Date: Thu, 30 Oct 2025 16:34:00 +0200
Message-ID: <CAMW7n8AYJpMT2HRo4H7LbNo=D6wm_Kb-1cjU43EtgwbFFgRgKg@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
To: Deleu <deleugyn@gmail.com>
Cc: 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)

Hi

> One minor question: is this section https://wiki.php.net/rfc/true_async#a=
waiting_a_result_with_cancellation named wrongly? I'm not sure how this sni=
ppet of code relates to cancellation.
Yes, second parameter is a CancellationToken. (spawn('sleep', 2)).

> What's the difference between Multishot Awaitables and Generators?
There=E2=80=99s nothing in common between them.
It=E2=80=99s better to think of asynchronous objects as components of an
EventDriven pattern.

> doesn't this mean that multishot awaitables are not really capable of bei=
ng awaited anymore?
Exactly. It=E2=80=99s not needed for now.

> Shouldn't FutureLike be Awaitable and what has been described as Multisho=
t awaitables should actually be generators / array of / list of Awaitables?
FutureLike is a child interface of Awaitables.

> we can assume that if a function used to throw an Exception and a future =
version stops throwing said exception it is not considered a BC Break.
This RFC does not change the behavior of existing functions. For
example, sleep works the same as before.
PHP functions that previously did not throw a CancellationError do not
throw it in this RFC either.
However, when you use functions (await example) that do throw these
exceptions, you handle them the same way as always. In that sense,
there=E2=80=99s no new paradigm.

> What if the first version of Async PHP provides userland with the ability=
 to trigger coroutines for reading purposes only?

Sorry, but I couldn=E2=80=99t understand why this needs to be done.
There=E2=80=99s nothing terrible about canceling write operations =E2=80=94=
 no
=E2=80=9Cshooting yourself in the foot=E2=80=9D either. A program can termi=
nate at any
moment; that=E2=80=99s perfectly normal.

The concept of Cancellation by Design isn=E2=80=99t about guns =E2=80=94 it=
=E2=80=99s about
reducing code. That=E2=80=99s all.
In the Swift language, for example, a different concept is used:
cancellation is always written explicitly in the code, like this:

```swift
func fetchData() async throws -> String {
    for i in 1...5 {
        try Task.checkCancellation()
        print("Fetching chunk \(i)...")
        try await Task.sleep(nanoseconds: 500_000_000)
    }
    return "Data loaded"
}
```

The only question is about how much code you write and the likelihood
of errors. The more code you write, the higher the chance of making
one.

Write safety is a different topic; it concerns how code is implemented
at the lowest level, meaning the code that calls OS functions.
Cancelling a coroutine cannot interrupt a kernel-level write operation
=E2=80=94 it can only interrupt waiting for the write, and what to do next =
is
decided by the user-level code.

The cancellation design was implemented as early as 2015 in Python
(and in other languages as well) and has worked perfectly since then.
For languages like PHP, it=E2=80=99s a convenient and, most importantly,
familiar mechanism. The real problem is that an exception can
accidentally be caught without exiting the coroutine. For example:
```php
catch (\Throwable $e) {
    Logger::log();
}
continue;
```