Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129230
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>
In-Reply-To: <6618a91c-5393-4f40-88b5-b5041ee09deb@app.fastmail.com>
Date: Sat, 15 Nov 2025 14:16:14 +0200
Message-ID: <CAMW7n8CeDFSaN0e4Kr=1jrJyHEonHokfxcY4gdf6L3FqdH1FZQ@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 all.

Some of these questions sound familiar. Let=E2=80=99s try to sort them out.

> If I have a tight loop processing data in memory (no I/O), will it monopo=
lise the coroutine scheduler? Do I need to manually insert suspend() calls?=
 How do I know when and where?

A coroutine must yield control on its own. If it keeps it through an
endless loop, then it will be the only one running.

> The RFC suggests that existing PHP functions won=E2=80=99t automatically =
be non-blocking. So which will? Is there a way to identify suspension point=
s at the language/API level?

The RFC does not say that. PHP I/O functions automatically become
non-blocking relative to the whole process. In other words, an I/O
function calls suspend() on its own when needed. The programmer writes
code exactly as before, under the illusion that operations are
executed one after another.

> Performance implications: Without knowing where suspensions occur, how do=
 developers avoid either:

In most cases, this is not the developer=E2=80=99s concern. Situations wher=
e
performance is critical should be handled with dedicated tools.
A PHP developer should not have to drop down to the C level. Properly
designed abstractions must provide the required performance.

I can already anticipate the question: but a developer could write
something like =E2=80=9Cfor i < 10000 suspend=E2=80=9D or something similar=
.
The answer is this: a developer must know how to use abstractions. As
always. Everywhere. In any area of programming.
It=E2=80=99s just as important as respecting proper layering in code.

Provided that PHP does not try to play the role of a C-level language
(there have already been such attempts, and they keep resurfacing),
and does not try to play a web server or a database system.
For most web scenarios, the current approach is more than sufficient.
This has been proven by Swoole, which has been on the market for many
years. Therefore, performance questions are outside the scope of this
RFC.

As for the concurrency model, let me remind you that Go has true
multitasking. Goroutines in Go, although they have a =E2=80=9Csynthetic=E2=
=80=9D
stack. But you already know all this well.
This RFC and its implementation describe coroutines in a single
thread. That is very far from what Go provides.

There is no preemptive multitasking in this RFC because it is
completely unrelated.
This RFC and its implementation provide cooperative concurrency in a
single thread, where coroutine code yields control on its own.
Why was this model chosen? The simple answer is: because it is the
only one that can realistically be implemented within a finite
timeframe.

Any more questions?

-- Ed