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 <larry@garfieldtech.com> 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