On Mon, Oct 27, 2025, at 11:18 AM, Alexandru Pătrănescu wrote: >> >> >> On Mon, Oct 27, 2025 at 6:05 PM Larry Garfield <[email protected]> >> wrote:
>>> I am not sure how feasible this is, but would there be a way to split the >>> "async toggle" of IO operations off to its own PR/RFC? To me, that is by >>> far the most important part of this RFC as that's the biggest blocker for >>> wider async adoption, but I'm not sure how many layers are needed above it >>> to make it possible to toggle in a safe fashion. >> >> Hi! >> >> Can you clarify what you mean by "async toggle"? >> Is it the actual implementation that would use async constructs if the >> current context is a coroutine for each implementation of IO functions? >> Yes, for that, it would be nice to have separate PRs, even multiple ones for >> easier review. But maybe you mean something else... >> >> -- >> Alex The most important feature of this RFC, IMO, is that when async is "active", all IO operations become non-blocking and automatically suspend an active coroutine, so that other coroutines can act. That means you can write file_get_contents() or whatever, and in non-async land it will block as normal, but in async land it will suspend and let other coroutines run, then pick up again when ready, without requiring any code changes. (At least that's how I understand that part of the RFC.) That is *huge*, and easily the most important feature. Really, if we had that in core it would be possible to do most of the rest in user-space with the existing Fibers, I suspect. But I don't know how feasible it is to separate that part out, in large part because it would mean exposing some kind of way to toggle if async is "active" (for some definition of active). But if that is possible/feasible, that would be a much narrower, more easily reviewable, and still highly useful RFC that could be iterated on in both user space and core. I do not know how coupled that is to the new Fiber-incompatible loop, which is the biggest problem. --Larry Garfield
