Re: Re: PHP True Async RFC Stage 5

From: Date: Sat, 15 Nov 2025 11:37:45 +0000
Subject: Re: Re: PHP True Async RFC Stage 5
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-129228@lists.php.net to get a copy of this message
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

« previous php.internals (#129228) next »