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
