Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128936
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> <CAMW7n8D3m-dsBJyq-vk09ft5Vx+6yHc8wrv2sbJ3EMVp+i4m=A@mail.gmail.com>
 <C92EA4F8-F76F-4B84-B573-5154D4A1C86E@zort.net> <CAMW7n8AZxiHRMbVbUFZfj=O4X68HkfoTzA8tLO407zHGiWXLTQ@mail.gmail.com>
 <F871B5D0-AC67-4697-B6A2-0462CF335B7E@zort.net>
In-Reply-To: <F871B5D0-AC67-4697-B6A2-0462CF335B7E@zort.net>
Date: Thu, 23 Oct 2025 19:44:14 +0300
Message-ID: <CAMW7n8CAC=ybwURmh7b8VZgB01i6FRfCqsM1LEX3C-BAgoRmDg@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

>  I don't have any specific use-cases in mind. I'm just trying to be forwa=
rd-looking here. But what is clear is that some people would like to see as=
ync/await in PHP. This RFC would ostensibly be a
> step towards that. All I'm trying to do is make sure that it doesn't put =
up roadblocks for future enhancements.
>

The main obstacles to multithreading are:
* The state of the PHP virtual machine, as well as how the bytecode is
stored (some elements cannot be transferred)
* The memory manager
* The garbage collector

Of course, for a multithreaded version, the scheduler would have to be
almost completely rewritten, but this task doesn=E2=80=99t seem as demandin=
g
as the ones above.

As for the RFC itself, it does not impose any additional limitations
beyond those already inherent to PHP.

If coroutines can be moved between threads, then all variables must be
thread-safe. How will that be guaranteed? The context of a `Closure`
must also be thread-safe, how will that be ensured?
All these questions are outside the scope of this RFC and relate to
the implementation of closures.

There is another risk here.
If PHP introduces async functionality that works within a single
thread, users will start writing code with closures, assuming it will
work correctly because everything runs in one thread.

The RFC does not regulate this at all, and that=E2=80=99s the problem.
Developers will begin writing code designed for single-threaded behavior.
If multithreading is later introduced, that code will inevitably break.

There=E2=80=99s much more that could be added here. The main point is that =
the
RFC is not designed around a memory model for parallelism, and such a
model should not be part of the RFC.

If you=E2=80=99re planning such changes for PHP, it would be wise to come u=
p
with a way to handle them.
But to do that, we first need to understand which memory model you=E2=80=99=
ll choose.
Will it be Actors + SharedState, meaning special kinds of closures, or
something else?

> Second: it should be emitting either a stream of files, or a stream of ar=
rays of files. Returning list<File>|File is not a great pattern.

I wasn=E2=80=99t suggesting doing that, I just wanted to show the differenc=
e
between =E2=80=9Cmultiple values=E2=80=9D and =E2=80=9Ca single value.=E2=
=80=9D

> That's the first review thread for Swift's Structured Concurrency proposa=
l.
> The proposal itself is here, along with links to the three pitch and thre=
e review threads, and the async/await and actor proposals:
Thank you. I will look at it.

> Why is the protect function needed, then? If you request cancellation, th=
e coroutine is free to ignore the cancellation and run to completion. That'=
s what makes it cooperative.
Because cancellation interrupts coroutine waiting.
If cancellation occurs deep within the runtime while it is writing a
buffer to a socket, it means that not all data will be written. That=E2=80=
=99s
exactly the case where protect is useful.

----
Thanks, Ed.