On Thu, Nov 13, 2025, at 10:01, Edmond Dantes wrote:
> Hello all.
>
> Today marks two weeks since the RFC was published.
>
> I need to apply a few minor fixes that Luis pointed out.
>
> If anyone else is working on comments for the RFC, please let me know.
> If there are no objections, we can start the vote on Monday.
>
> Best regards, Ed
I have concerns about the clarity of when suspension occurs in this RFC.
The RFC states as a core goal:
"Code that was originally written and intended to run outside of a Coroutine must work EXACTLY
THE SAME inside a Coroutine without modifications.."
And:
"A PHP developer should not have to think about how Coroutine switch and should not need to
manage their switching—except in special cases where they consciously choose to intervene in this
logic."
However, the RFC doesn’t clearly define what these "special cases" are or provide
guidance on when developers need to intervene.
Specific questions:
1. CPU-bound operations: If I have a tight loop processing data in memory (no I/O), will it
monopolise the coroutine scheduler? Do I need to manually insert suspend() calls? How
do I know when and where?
2. The RFC suggests that existing PHP functions won’t automatically be non-blocking. So which
will? Is there a way to identify suspension points at the language/API level?
3. Performance implications: Without knowing where suspensions occur, how do developers avoid
either:
- Starving other coroutines (too few suspensions)
- Degrading performance (too many suspensions)
With explicit async/await ("coloured functions"), developers know exactly where suspension
can occur. This RFC’s implicit model seems convenient, but without clear rules about suspension
points, I’m unclear how developers can write correct concurrent code or reason about performance.
Could the RFC clarify the rules for when automatic suspension occurs versus when manual
suspend() calls are required? Is this RFC following Go’s model where suspension
timing is an implementation detail developers shouldn’t rely on? If so, that should be stated
explicitly. Keep in mind that Go didn’t start that way and took nearly a decade to get there.
Earlier versions of Go explicitly stated where suspensions were.
— Rob