Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129241
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
 <CAMW7n8Dp3siTp0NKGc=-8aNg=Mqoxug9Osgn2399P1v4wi3n5Q@mail.gmail.com>
 <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com> <CAMW7n8CeDFSaN0e4Kr=1jrJyHEonHokfxcY4gdf6L3FqdH1FZQ@mail.gmail.com>
 <3e0cf0a1-c1a3-4e05-97ba-0eeb7f559a53@app.fastmail.com> <CAMW7n8AX7O7x99KGdPSai6sPP1Xd6V4ojQ7CEWmxthNLPM2hyQ@mail.gmail.com>
 <d17e07bf-9664-48e8-b7c4-39142f3cfbf2@app.fastmail.com>
In-Reply-To: <d17e07bf-9664-48e8-b7c4-39142f3cfbf2@app.fastmail.com>
Date: Sat, 15 Nov 2025 23:20:21 +0200
Message-ID: <CAMW7n8D3Mq6PveYxvfx=Djx6GnpkECOsEsEc2yKtJACAkAoLpQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5
To: Rob Landers <rob@bottled.codes>
Cc: php internals <internals@lists.php.net>, Jakub Zelenka <bukka@php.net>, 
	Larry Garfield <larry@garfieldtech.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Hello.

> An array_map() always blocks the thread but should never suspend.
This function is not related to this discussion or to the RFC.

> Without very clear rules, it becomes impossible to reason about what=E2=
=80=99ll suspend and what won=E2=80=99t.
As I mentioned earlier, this RFC clearly defines the rules for
integrating functions. The functions themselves will be documented.

> That=E2=80=99s not quite enough. The order really matters. Different sche=
dulers produce different observable results.
No modern language guarantees a fixed execution order of coroutines.
Go, Kotlin, Python, JavaScript, C#, Rust. All only guarantee order
when explicit synchronization is used.
Everything else is an implementation detail of the scheduler, and user
code must not rely on it.
(Because concurrency naturally has many valid execution paths, not one.
Forcing a single fixed order is impossible without adding heavy
synchronization everywhere, which destroys performance and breaks the
concurrency model.)

> Unfortunately, I can=E2=80=99t find a link to documentation that old.
no one can

> I may be missing something, but I don=E2=80=99t see this spelled out anyw=
here in the RFC.
What exactly were you unable to find?

> Right now, without suspension rules, scheduler guarantees, defined syscal=
l-cancellation semantics, it=E2=80=99s tough to evaluate the correctness an=
d performance implications.
> Leaving some of the most important aspects as an "implementation detail" =
seems like asking for trouble.

I=E2=80=99m sorry, but it=E2=80=99s difficult for me to understand what thi=
s is referring to.