Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128909
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Wed, 22 Oct 2025 19:40:01 +0200
To: "John Bafford" <jbafford@zort.net>, "Edmond Dantes" <edmond.ht@gmail.com>
Cc: "Aleksander Machniak" <alec@alec.pl>,
 "PHP Internals" <internals@lists.php.net>
Message-ID: <9ec19485-61cc-460b-adeb-1b2262a68578@app.fastmail.com>
In-Reply-To: <C3EEAC36-A8ED-4B82-BDFC-879EF923E079@zort.net>
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>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 4
Content-Type: multipart/alternative;
 boundary=7a8815f477054b949901fad6ea66db47
From: rob@bottled.codes ("Rob Landers")

--7a8815f477054b949901fad6ea66db47
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, Oct 22, 2025, at 19:24, John Bafford wrote:
> Hi Edmond,
>=20
> > On Oct 22, 2025, at 09:09, Edmond Dantes <edmond.ht@gmail.com> wrote:
>=20
> Thanks for putting in the work to start to bring async support to PHP.=
 I have a few initial comments:
>=20
>=20
> * Is TrueAsync intended strictly to enable concurrency without paralle=
lism (e.g. single-threaded cooperative multitasking)? Is there a future =
path in mind for parallelism (actual simultaneous execution)?
>=20
>=20
>=20
> * Following on from that question, I note that there is no way to anno=
tate types as being safely sendable across concurrent execution contexts=
. PHP does have a thread-safe ZTS mode. And a long-term goal should be t=
o allow for parallel (multiple concurrent execution) asynchronous tasks,=
 especially if we want to expand asynchronous from just being a way to a=
ccomplish other single-threaded work while waiting on I/O.
>=20
> In a concurrent environment, one has to consider the effects of multip=
le threads trying to read or write from the same value at once. (Strictl=
y speaking, even in a single-threaded world, that's not necessarily safe=
 to ignore; the stdclib or kernel code behind the scenes may be doing al=
l sorts of shenanigans with I/O behind everyone's back, though I suspect=
 an async-aware PHP could itself be a sufficient buffer between that and=
 userspace code.)
>=20
> With multithreaded code, it's generally not safe to pass around types =
unless you can reason about whether it's actually safe to do so. This co=
uld be trivially encoded in the type system with, say, a marker interfac=
e that declares that a type is safe to send across threads. But this nee=
ds to be opt-in, and the compiler needs to enforce it, or else you lose =
all pretense of safety.
>=20
> It's tempting to handwave this now, but adding it in later might prove=
 intractable due to the implied BC break. E.g. trivially, any call to sp=
awn() might have its task scheduled on a different thread, but you can't=
 do that safely unless you know all types involved are thread-safe. And =
while you could determine that at runtime, that's far more expensive and=
 error-prone than making the compiler do it.
>=20
> That said: the TrueAsync proposal isn't proposing async/await keywords=
. Perhaps it's sufficient to say that "TrueAsync" is single-thread only,=
 and the multithreaded case will be handled with a completely different =
API later so BC isn't an issue. But either way, this should be at least =
mentioned in the Future Scope section.

Off-topic a bit: but for the last several+ weeks, I=E2=80=99ve been rewo=
rking TSRM (moving it into Zend & making it a bit more frankenphp friend=
ly) which could -- eventually -- allow for passing arbitrary types betwe=
en threads without complex serialization and shenanigans.

=E2=80=94 Rob
--7a8815f477054b949901fad6ea66db47
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Wed, Oct 22, 2025, at 19:24, John Bafford wrote:</d=
iv><blockquote type=3D"cite" id=3D"qt" style=3D""><div>Hi Edmond,</div><=
div><br></div><div>&gt; On Oct 22, 2025, at 09:09, Edmond Dantes &lt;<a =
href=3D"mailto:edmond.ht@gmail.com">edmond.ht@gmail.com</a>&gt; wrote:</=
div><div><br></div><div>Thanks for putting in the work to start to bring=
 async support to PHP. I have a few initial comments:</div><div><br></di=
v><div><br></div><div>* Is TrueAsync intended strictly to enable concurr=
ency without parallelism (e.g. single-threaded cooperative multitasking)=
? Is there a future path in mind for parallelism (actual simultaneous ex=
ecution)?</div><div><br></div><div><br></div><div><br></div><div>* Follo=
wing on from that question, I note that there is no way to annotate type=
s as being safely sendable across concurrent execution contexts. PHP doe=
s have a thread-safe ZTS mode. And a long-term goal should be to allow f=
or parallel (multiple concurrent execution) asynchronous tasks, especial=
ly if we want to expand asynchronous from just being a way to accomplish=
 other single-threaded work while waiting on I/O.</div><div><br></div><d=
iv>In a concurrent environment, one has to consider the effects of multi=
ple threads trying to read or write from the same value at once. (Strict=
ly speaking, even in a single-threaded world, that's not necessarily saf=
e to ignore; the stdclib or kernel code behind the scenes may be doing a=
ll sorts of shenanigans with I/O behind everyone's back, though I suspec=
t an async-aware PHP could itself be a sufficient buffer between that an=
d userspace code.)</div><div><br></div><div>With multithreaded code, it'=
s generally not safe to pass around types unless you can reason about wh=
ether it's actually safe to do so. This could be trivially encoded in th=
e type system with, say, a marker interface that declares that a type is=
 safe to send across threads. But this needs to be opt-in, and the compi=
ler needs to enforce it, or else you lose all pretense of safety.</div><=
div><br></div><div>It's tempting to handwave this now, but adding it in =
later might prove intractable due to the implied BC break. E.g. triviall=
y, any call to spawn() might have its task scheduled on a different thre=
ad, but you can't do that safely unless you know all types involved are =
thread-safe. And while you could determine that at runtime, that's far m=
ore expensive and error-prone than making the compiler do it.</div><div>=
<br></div><div>That said: the TrueAsync proposal isn't proposing async/a=
wait keywords. Perhaps it's sufficient to say that "TrueAsync" is single=
-thread only, and the multithreaded case will be handled with a complete=
ly different API later so BC isn't an issue. But either way, this should=
 be at least mentioned in the Future Scope section.</div></blockquote><d=
iv><br></div><div>Off-topic a bit: but for the last several+ weeks, I=E2=
=80=99ve been reworking TSRM (moving it into Zend &amp; making it a bit =
more frankenphp friendly) which could -- eventually -- allow for passing=
 arbitrary types between threads without complex serialization and shena=
nigans.<br></div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</=
div></body></html>
--7a8815f477054b949901fad6ea66db47--