On Sun, 23 Nov 2025 at 21:29 Luís Vinícius Santos da Costa Barros < [email protected]> wrote:
> Hello, > > I have serious concerns about any approach that may cause the event loop > to block. The correct ways to handle this should not involve blocking the > loop — whether globally or in a scoped manner — while attempting to let > synchronous and asynchronous code coexist in the same environment. More > appropriate alternatives would be offloading execution to another thread > (which is far too complex for the current VM and ecosystem) or relying on > preemption (which is not feasible to implement here). > > In addition, the cascading effects of such an approach are significant: > libraries would be forced to implement internal mechanisms just to deal > with unexpected loop stalls and similar issues. > > It would be much healthier for new libraries to be designed specifically > for the asynchronous environment, in the same way Laravel created Octane to > run on top of Swoole. > If I could summarize months of discussion on this RFC, the primary topic would be the consensus that we do not want to have a split in the community. If every PHP package needs an adapter to be async compatible that essentially means the efforts to not break the community in half has failed. A different way to look at it may be that it’s not so much about blocking the event loop, but rather not even having an event loop in the first place (in case you’re running sync-PHP). And if you’re partially running async at an isolated area, then once that returns and all coroutines are finished the event loop may also finish and we’re back to sync. >
