Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129034
Message-ID: <2441aa9c-41c8-4ce1-b9c0-67136e5f97da@dennis.birkholz.biz>
Date: Fri, 31 Oct 2025 23:59:37 +0100
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] PHP True Async RFC Stage 5
To: internals@lists.php.net
References: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
Content-Language: de-DE, en-US
In-Reply-To: <CAMW7n8DiWK6y=76cRTpx+6eGmBgytd2HWs2C-OH5rd8WNLffFA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: php@dennis.birkholz.biz (Dennis Birkholz)

Hi Edmond,

Am 30.10.25 um 9:19 AM schrieb Edmond Dantes:
> Hi
>
> 1.5 RFC:
> https://wiki.php.net/rfc/true_async

first of all thank you for investing so much time and effort into 
improving PHP.

The True Async RFC changed a lot in the past iterations and removed a 
lot of related but tangential topics. I really appreciate your 
willingness to adapt to get the best possible outcome.

What I now see is as far as I understand essentially a Fiber 2.0 RFC so 
I wonder if it would not be better to improve the available Fibers 
instead of creating an incompatible second mechanism.

The Coroutine class is essentially a Fiber class that can be cancelled 
and restricted by a cancellation awaitable.
The Fiber class could get startWithTimeout($timeout, ...$args) and 
resumeWithTimeout($timeout, mixed $value = null) methods as well as a 
cancel() method.
It wouldn't be a Fiber in the pure compsci way any more but I am willing 
to accept that if it prevents us from having two ways for (semi) 
cooperative multitasking.

The part about how the Awaitable and FutureLike interfaces work is very 
unclear to me. They are there but they do not describe how they could be 
used in a truly multitasking fashion. That is somehow open to the 
Scheduler/Reactor which are not described to reduce the complexity.
The RFC as it is allows to `await(new Coroutine())` which is syntactical 
sugar for `$fiber = new Fiber(); $fiber->start(); while 
(!$fiber->isTerminated()) $fiber->resume();` So a followup RFC would 
need introduce this additional mechanism into these interfaces.

Also I do not really understand why the "cancellation" is an awaitable. 
If the provided awaitable is itself some infinitely blocking Coroutine 
(e.g. `while (true) {}`), how can the scheduler run the actual Coroutine 
and the "cancellation" awaitable to determine whether the Coroutine 
should be cancelled or not? As long as there is no multithreading, this 
does not make sense for me.

In addition, what happens if a Coroutine is suspended and is restarted 
again. Is the cancellation awaitable restarted? Or just continued?

I am really skeptical if the current RFC is the right way to go, 
establishing a Coroutine and Awaitable and FutureLike interfaces in 
competition to the existing Fiber.

I would rather see a step-by-step plan with gradual improvements like this:

1. Propose some changes to Fiber so it can be interrupted after a timer 
expired and it can be cancelled.

2. Add a unified polling mechanism for all kinds of IO events (timeouts 
and signals included) like Jakub's "Polling API".

3. Enhance the Fiber class so it can expose a PollHandle/Pollable that 
it is currently waiting on, either as a property of the Fiber 
(Fiber::$pollHandle) or as a `Fiber::suspendPolling(PollHandle 
$pollHandle, mixed $value = null)` method.

4. Now internal IO methods can be changed to start a pollable Fiber 
instead of blocking the execution if they are started in a specific way 
(e.g. by a then introduced spawn() call).

5. With all that in place, userland can now create their own 
Scheduler/Rector. The Core could also include a simple default 
implementation used the PollContext/PollWatcher in addition with a 
scheduling policy for other Fibers.

Kind regards
Dennis