Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129286
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>
 <CAMW7n8A7hKV3xUjd2DvmEtM=RxWQ2cwSVbo9FGiGg9Jy93o9DQ@mail.gmail.com> <563f3bc0-d7f5-4bb9-915c-1d63601d2300@rwec.co.uk>
In-Reply-To: <563f3bc0-d7f5-4bb9-915c-1d63601d2300@rwec.co.uk>
Date: Tue, 18 Nov 2025 08:46:25 +0200
Message-ID: <CAMW7n8AeTew4NDtei7bPdzV1weFBQmgMQ98M4JUnwNAXQNPOeA@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: PHP True Async RFC Stage 5
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
From: edmond.ht@gmail.com (Edmond Dantes)

Hello.

> Larry's "sync" marker would be a change to *run-time behaviour*: when
> myFun() begins, the scheduler switches into "linear mode", until the end
> of that function. In that mode, when a suspend() point is reached, the
> scheduler immediately resumes that coroutine rather than choosing a
> different one.

This is very similar to the async\protect mechanism, but with a
restriction that forbids switching inside IO functions. It is possible
to implement this, but other coroutines will experience serious
starvation. In other words, it can be done, but it should not be done.

Concurrency works well when the programmer follows one rule. Every
coroutine must have many suspension points, and the time between these
points must not exceed a certain value. This is a typical scenario for
web applications. It is not universal. There are completely different
scenarios. For example, a PHP linter.

For a PHP linter, parallel execution will be more useful. Async
functions can also help when combined with threads. The architecture
will be as follows.

* A job manager that monitors execution where one coroutine is one task.
* A pool of threads where there are almost no coroutines.

The job manager creates a coroutine that sends a task to a separate
thread and handles it.
It can also perform IO. In the separate thread, coroutines are not
really needed because the code mostly performs heavy computations.
Of course, TrueAsync will provide the programmer with a channel for
interacting with a coroutine in another thread, and that interaction
will also be asynchronous.
This approach is 100 percent memory-safe because it fully controls
which object is passed through the channel.

In other words, by understanding the strong side of coroutines and
having tools like a thread pool, a programmer can build PHP
applications without true parallelism that will not be inferior to Go.
The only downside is that you have to manually split the code into an
IO stream and a job worker. This adds a bit of development time, but
not critically.

---
Best regards, Ed