Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129235
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> <12D52EE4-62F4-42AC-A17D-A8F3A19D2433@zort.net>
In-Reply-To: <12D52EE4-62F4-42AC-A17D-A8F3A19D2433@zort.net>
Date: Sat, 15 Nov 2025 19:22:03 +0200
Message-ID: <CAMW7n8AuPXBqFMi=WCk=8=OR=SmWnfP1-=Ct1DbkcvfmFUt=2Q@mail.gmail.com>
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
To: John Bafford <jbafford@zort.net>
Cc: Rob Landers <rob@bottled.codes>, 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)

> To provide an explicit example for this, code that fits this pattern is g=
oing to be problematic

Why is this considered a problem if this behavior is part of the
language=E2=80=99s contract?
Exactly the same way as in Go for example, this is also part of the
contract between the language and the programmer.

> $this->data can be changed out from under writeData(), which leads to une=
xpected behavior.

So the developer must intentionally create two different coroutines.
Intentionally pass them the same object.
Intentionally write this code.
And the behavior is called =E2=80=9Cunexpected=E2=80=9D? :)

> that it is working "exactly the same" with coroutines by ignoring that it=
 is now wrong
I understand that a word written by one person can be interpreted
however another person feels like.
Language is not a reliable carrier of information, so people must take
context into account to extract useful information with minimal
distortion.

The changes described in the RFC refer to the algorithm for handling
I/O functions in blocking mode. And of course these words assume that
we haven=E2=80=99t lost our minds and understand that you cannot write
completely different message sequences to the same socket at the same
time. In practice, changes are of course sometimes necessary, but
throughout my entire experience working with coroutines, I should note
that I have never once run into the example you mentioned. Even when
adapting older projects. And do you know why? Because the first thing
we refactored in the old code was the places with shared variables.

>  There is no way in general for code written without coroutines or async =
suspensions in mind to work correctly if it can be suspended.

Agreed.

A developer must understand that potentially any function can
interrupt execution. This is a consequence of transparent asynchrony.
It is both its strength and its weakness. I will repeat it again: not
some specific function, but almost ANY function. Because under
transparent asynchrony you can use suspend() inside any function. This
does not negate the fact that documentation should list all functions
that switch context, but a certain coding style encourages this way of
thinking.

Modern programming languages strive for clarity and cleanliness. In
other words, colored functions provide code clarity and prevent errors
caused by misunderstanding what a function does. Critics of colored
functions criticize them precisely for what is actually their
strength, not their weakness. Color is an advantage.

But in PHP, colored functions are inconvenient. Overloading I/O
functions does not lead to serious errors that make developers suffer;
on the contrary, it saves time and gives the language more
flexibility.

I can explain why. The amount of code that works with sockets in PHP
is generally several times smaller than the code that works with
databases. In other words, the modules where such errors could occur
are simply not that many. They do exist. library clients... but
compared to all other code, there are far fewer of them. And as it
turns out, refactoring them for coroutines requires very few changes.
Especially if the code was already well-written with best practices in
mind, then it will most likely work excellently with coroutines with
minimal adjustments.

How did we refactor old code for coroutines?

1. We took the modules that had global state. There were not many of them.
2. We used a Context, which is essential, and moved the global state
into the context.

I don=E2=80=99t remember exactly how many thousands of lines of code there
were, but definitely more than 20,000.
But why anyone would intentionally pass the same object to different
coroutines and then complain that the code broke. I have no idea who
would need that. :)

A developer should strive to minimize asynchronous code in a project.
The less of it there is, the better. Asynchronous code is evil. An
anti-pattern. A high-complexity zone. But if a developer chooses to
use asynchronous code, they shouldn=E2=80=99t act like they=E2=80=99re thre=
e years old
and seeing a computer for the first time. Definitely not. This
technology requires steady, capable hands :)

Best Regards, Ed.