Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129278
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> <CAEKnhAHp9fCOD0NCLE9J25dTkVd72csHGb3HGwATg+qyxNaFwg@mail.gmail.com>
 <41c5eed0-dd1b-4ea4-99cf-f6d16682bd7f@app.fastmail.com> <CAEKnhAEmSZn=Tr24YC9wxAUk1NPM529GR_iBWmX=fKpXxpuXRg@mail.gmail.com>
 <f777dba4-b29f-4744-889e-131ec730e305@app.fastmail.com> <CAMW7n8AovFXC6by4AyAwh0U9Gax2UQ-MkkpwqCPkP8hNz52hew@mail.gmail.com>
 <08303459-b4ab-44a8-9795-0fb7f82914d0@app.fastmail.com> <fd02e7f9-16df-446e-8f59-46ffbd85b657@app.fastmail.com>
In-Reply-To: <fd02e7f9-16df-446e-8f59-46ffbd85b657@app.fastmail.com>
Date: Mon, 17 Nov 2025 11:49:14 +0200
Message-ID: <CAMW7n8A7hKV3xUjd2DvmEtM=RxWQ2cwSVbo9FGiGg9Jy93o9DQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5
Cc: 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)

Hello Larry

Regarding the phrase about =E2=80=9Cproblems with mutable shared state=E2=
=80=9D.

In this context, when I say =E2=80=9Cproblem,=E2=80=9D I mean something tha=
t
significantly worsens development. =E2=80=9CNot a problem=E2=80=9D does not=
 mean that
errors never occur. It means that resolving them takes an acceptable
amount of time. This phenomenon has reasonable explanations:

1. Developers usually know where they use global state. And even if
they don=E2=80=99t, they know that this is the first thing to check. That
helps a lot.
2. Bugs involving shared memory are usually easy to reproduce (which
is rare in asynchronous programming). This drastically reduces
debugging time.
3. In a single-threaded environment, shared-state bugs are much
simpler. For example, the probability of corrupting data structures is
relatively low.
4. In PHP projects, shared state is typically used in a small set of
scenarios, and these scenarios are usually simple, which also
minimizes the time needed to fix issues.

For example: some global variable stores a SessionId. And then it
turns out that an action was recorded not for the user who performed
it, but for another one with a different session. In most cases, the
bug report alone already points you directly to where you need to
look.

My point is not that you should ignore shared-memory bugs, but that
you shouldn=E2=80=99t fear them or treat them as something huge.

I also want to remind that in programming there are no =E2=80=9Cbad=E2=80=
=9D
approaches or technologies. Shared mutable state is a very useful
thing and should be used. For caching, for storing session data, for
access-rights memoization, and so on. You don=E2=80=99t need to avoid share=
d
state. You need good tools, patterns, and proper practices. As for
language-level abstraction, features like `local $var`, effects, and
context will help make the code safer.
Monads would also fit PHP well, as they allow expressing parallelism
better than procedural code.

> That's what I think we all want to NOT have in PHP.
Exactly. PHP exists to save money, not to spend it. Recently there was
an article about Python describing the problems caused by having
multiple runtimes.

> Third: So my question would be, is there a practical middle-ground?
> Is there a syntax and semantics we could define that would cover *most* e=
dge cases existing code may have involving shared mutable state automatical=
ly

Based on the current state of programming languages, there is no good
solution. Only radical ones like Actors, Arenas, and so on. All of
them rely on complete memory isolation. But that=E2=80=99s not the point. T=
he
point is that PHP still has legacy code, and you cannot just throw it
away.

> the RFC right now says "any IO operation, implicitly, hope that's OK."

Go does the same thing, and it=E2=80=99s a very convenient mechanism.
There is a small percentage of cases where this breaks the logic.
Here is one of them:

```php
$start =3D microtime(true);
$data =3D file_get_contents('data.txt');

$elapsed =3D microtime(true) - $start;

if ($elapsed > 0.001) {
    echo "Reading took too long\n";
}
```

The code breaks only in two cases:
1. When there is usage of mutable shared memory/shared resource
2. When there is logic based on a timer

Yes, such code will break inside a coroutine. But should we be afraid
of that? I don=E2=80=99t think so. The likelihood of this kind of logic is
very low. And if needed, this case can be explicitly documented.

Besides this case, special attention is also needed for:

* libraries that use sockets
* libraries that use threads
* libraries that use processes

But this does not mean there will necessarily be major or serious
problems adapting the code. PHP already has experience with Swoole,
and Swoole works exactly the same way as the code in this RFC. For
example, adapting the RabbitMQ library for Swoole required changing
about 10=E2=80=9320 lines of code, roughly 2=E2=80=933 days of work. Most o=
f the time
was spent on testing.

Regarding the hybrid function-tainting model, it is designed for
compilers or static analysis. For PHP, it could be implemented like
this:

```php
#NoAsync
function myFun() {
    asyncFun(); // Error <---
}

function asyncFun() {}
```

This is a solvable task for static analysis.