Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129374
Precedence: list
MIME-Version: 1.0
References: <CAMW7n8D0QshP8VhGOUqVnC+Uwf88TC_yy_mQdeNZW_go5YLdcw@mail.gmail.com>
 <C58ADF49-6E21-4E25-8859-2A0769829E38@php.net> <e8625214-1c6f-40b8-b24f-e592e6f92012@beccati.com>
 <CAMW7n8Dy3=QyCrG4BMwVXWAipgOr2Vyhy_jbLVTYeq2Jc5v15g@mail.gmail.com>
 <dbc31109-a43d-4afc-9f4f-62c6439328e5@rwec.co.uk> <ea59722c-2c84-4a59-a442-a8b217ff577d@gmail.com>
 <b151687a-f4bd-48cf-90e6-440f763ccd6b@rwec.co.uk> <CAMW7n8CLZ7yFhUhh89wx7L+YwQ25LA7HZoGWUFB3R76KgXko2w@mail.gmail.com>
 <CAEKnhAHRPbiU4auDuTtFL2ueNnACjmYm_ff9c3VciYE9HfeGZg@mail.gmail.com>
 <CAMW7n8D5B=XVX_Jes+LV=2fPwjQr_RBVphPi_Cxm8-_Rwpdo_Q@mail.gmail.com>
 <CADK1yX+jGtqQVYFTo5YmkenPrNcXz7Dd7RCUKWGrq+50pnKOnw@mail.gmail.com>
 <CAMW7n8Dogjj2JFJBNArk-BfvOHRqHKMAFReXJAhDm2UPV1TF7A@mail.gmail.com> <f388fc8b-6237-4c7c-9e4c-31a02f7f2daa@app.fastmail.com>
In-Reply-To: <f388fc8b-6237-4c7c-9e4c-31a02f7f2daa@app.fastmail.com>
Date: Fri, 21 Nov 2025 17:38:15 +0200
Message-ID: <CAMW7n8Cnyb05YbNBOYwrcB0V8niy_agMo2w8P0LPhwPWwPm8DA@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] True Async RFC 1.6
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: edmond.ht@gmail.com (Edmond Dantes)

Hello

> Without well-defined suspension points, literally all code is unpredictab=
le. This is what people have been trying to tell you for the last several w=
eeks. How can I know when the code will yield to the scheduler?
> How do I reason about it? The foundation is there in the RFC and the code=
, but it needs more definition and guarantees.

What guarantee does suspend() give? You can still break the code with
it. I understand what you=E2=80=99re talking about, but I don=E2=80=99t see=
 a big
difference between situations like these:

```php
// ---------------------------
// 1. File get contents suspend inside PHP CORE
// ---------------------------

$data =3D ['value' =3D> 1];
$content =3D file_get_contents('http://example.com');
$data['value'] =3D 2;

// ---------------------------
// 2. Asynchronous version special API
// ---------------------------

$data =3D ['value' =3D> 1];
// Yes we know about this here.
$content =3D file_get_contents_async('http://example.com');
$data['value'] =3D 2; // write happens after resume, timing is different
```

I understand that you are trying to say that if `file_get_contents` is
blocking, then there is *slightly more chance* that the code won=E2=80=99t
break.
And if `file_get_contents_async` is explicitly non-blocking, then the
programmer will have to rewrite the code.

But which is cheaper:

1. Rewrite **all** the code?
2. Or rewrite **only the code that uses shared memory**?

And at the same time, using `file_get_contents_async` does **not**
save the programmer from mistakes.
I can already imagine a situation where a programmer, trying to adapt
the code for async, simply renames the functions hoping it will =E2=80=9Cju=
st
work=E2=80=9D :)
No. It's not!

This approach:

* Increases the amount of refactoring
* Does not protect you from errors

> The foundation is there in the RFC and the code, but it needs more defini=
tion and guarantees.
There is another approach.
You can use a special `async` attribute for functions that support it.
This would allow not only highlighting the code in the editor, but
also validating it with static analysis.

In transparent asynchrony there is a rule when writing code.
Only code that makes no function calls at all is considered guaranteed safe=
.
Any call is potentially treated as a hypothetical yield point. I use
the same mindset when writing highly reliable code.
I imagine that it can crash literally at any line. The principle here
is similar.

Asynchronous code in this sense is always divided into two major parts:

1. code that accesses shared memory
2. code that does **not** access shared memory

You only need to be careful in the first case. Everything else
requires no special attention.

This leads to other principles:

1. Shared state should only be passed when it is truly necessary.
2. If an object can be made immutable, it *should* be immutable.
3. If an object must be mutable, then it deserves double attention.

Above these principles there is one more, the most important:

* if you can avoid writing asynchronous code, you should avoid it

> Global state is a core part of PHP, like it or not.

I love the global state. I=E2=80=99m not one of those people who shout that
some approach is =E2=80=9Cbad.=E2=80=9D
Global state is great. The only question is how and when to use it.

So... summary:
Coroutines require:

1. A framework that can work correctly in an asynchronous environment.
2. A different mindset for framework and library developers.
3. More knowledge from regular developers =E2=80=94 a bit of a minus=E2=80=
=A6 and a
plus at the same time.
4. Strict memory discipline for everyone. Hooray! This is the future
of programming. You can=E2=80=99t run away from it.

I=E2=80=99m confident that PHP can be adapted for more convenient memory
handling. There are possibilities for that.... at the syntax level and
at the helper-object level. This still needs discussion.

P.S.
If someone ever writes documentation, these would be excellent phrases for =
it :)