Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128913
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> <CAMW7n8B_+fBQEWoB6f2nNM7CPH5MfAHQ154dbyMLmDCS6-4Mhw@mail.gmail.com>
 <C3EEAC36-A8ED-4B82-BDFC-879EF923E079@zort.net>
In-Reply-To: <C3EEAC36-A8ED-4B82-BDFC-879EF923E079@zort.net>
Date: Wed, 22 Oct 2025 22:43:35 +0300
Message-ID: <CAMW7n8D3m-dsBJyq-vk09ft5Vx+6yHc8wrv2sbJ3EMVp+i4m=A@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
To: John Bafford <jbafford@zort.net>
Cc: Rob Landers <rob@bottled.codes>, Aleksander Machniak <alec@alec.pl>, 
	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

> * Is TrueAsync intended strictly to enable concurrency without parallelis=
m (e.g. single-threaded cooperative multitasking)?
> Is there a future path in mind for parallelism (actual simultaneous execu=
tion)?

In short, it mostly depends on the PHP core. TrueAsync itself could
support multithreading.
At the moment, achieving a fully multithreaded PHP seems extremely
complex and offers very little benefit.
In other words, the cost-to-benefit ratio is close to =E2=80=9Cirrational.=
=E2=80=9D

If you=E2=80=99d like, I can elaborate on this idea, though probably not in=
 this thread.

>  Following on from that question, I note that there is no way to annotate=
 types as being safely sendable across concurrent execution contexts

I actually studied this topic about a year ago. All of this can be
done if one really wants to.
To put it simply, implementing a SharedObject is already possible now,
and it seems that it already exists in the parallel extension.

As for data types and deep changes to PHP, that=E2=80=99s not directly rela=
ted
to TrueAsync. And even if it is, it can always be changed in the
future.
If someone decides to create a parallel version of PHP, they will
definitely face backward compatibility issues. I wouldn=E2=80=99t even worr=
y
about that :)

> That said: the TrueAsync proposal isn't proposing async/await keywords.
There is an RFC proposing new syntax, but it was unanimously decided
not to use it. For now. Maybe in PHP 9?

> Perhaps it's sufficient to say that "TrueAsync" is single-thread only, an=
d the multithreaded case will be handled with a completely different API la=
ter so BC isn't an issue. But either way, this should > be at least mention=
ed in the Future Scope section.
Yes, of course, that=E2=80=99s possible.

> * Rob Landers brought up the question about multiple-value Awaitables.
> I agree with him that it is a potential footgun. If an Awaitable is going=
 to return multiple values, then it should implement have a different inter=
face to indicate that contract.

It seems to me that this discussion has gotten a bit tangled:

1. Functions like awaitXX are not part of this RFC, yet we=E2=80=99re
discussing them. Is that really necessary?
2. Awaitable objects do not return multiple values.
3. The Awaitable interface is basic for others, just like in many
other programming languages. And for some reason, it=E2=80=99s not consider=
ed
a problem there.
So far, no real example has been found where this would actually be a probl=
em.

> For example: Swift's standard library provides the AsyncSequence

Comparing the Swift model directly with TrueAsync would be quite
difficult, and such a discussion would require studying Swift=E2=80=99s
implementation.
It=E2=80=99s not even worth comparing it to Rust, since Rust has its own
Future-based model, while Swift relies on code generation.
I haven=E2=80=99t looked deeply into this topic, so I can=E2=80=99t really =
add much more.

It would be good to fully figure things out with PHP first :)

> The answer in Swift to what happens if multiple readers await a non-idemp=
otent Awaiter

This is the general approach for the Event-Driven pattern, because
asynchronous execution under the hood is event-driven.
That=E2=80=99s exactly why the Awaitable exists. It acts as an EventProvide=
r,
and await() is effectively a subscription to events.
Therefore, when await, awaitAll, or awaitAny is called, the code
receives the first event, not multiple events.

> I don't have a particular view on whether values should be replicated to =
multiple readers or not,
> but I do find it a bit annoying that Swift's standard library doesn't pro=
vide an easy way to get replicated values.

The current RFC does not prohibit this. It does not restrict how
objects produce their results or how many subscribers they send them
to. This behavior is part of the object=E2=80=99s own contract.

> For cancellation, I'm confused on the resulting value.
Thank you, that=E2=80=99s a great catch!!!
I need to check this case.

> For clarity, the case when exit/die is called outside of async code
In TrueAsync, there is no longer any non-asynchronous code. Everything
is a coroutine.
Actually, that=E2=80=99s not entirely accurate, but it=E2=80=99s fine to th=
ink of it that way.

>  I think Async\protect() and forcibly cancelling coroutines beyond callin=
g $coroutine->cancel() should be removed.

If PHP were a language for spacecraft or airplanes, where extremely
high reliability is required, this might make sense.
However, the current model allows for more concise code and has
already proven itself well in other languages.

I actually have a stricter explanation for why the cancellable model
is more advantageous than any other.
This particular model fits well for read operations, which are usually
as frequent as, or even more frequent than, write operations.
Therefore, this approach simplifies asynchronous code while keeping
the overall risk low.

> Yes, this means that a coroutine might never complete.
> But this is no different than non-async code calling a function that has =
an infinite loop and never returns.

The cancellation (a cooperative cancellation model) mechanism does not
exist to interrupt infinite loops.
It is designed to provide a simple yet powerful way to cancel
coroutines that are running normally.
=E2=80=9CNormally=E2=80=9D means without an infinite loop.

> Also bikeshedding, but I would suggest renaming Coroutine to Task.
It could be named that way too. Although I don=E2=80=99t think there=E2=80=
=99s much
difference here. But Task is a shorter word.

Thanks, Ed