Hi, On Sat, Nov 15, 2025 at 8:56 PM Rob Landers <[email protected]> wrote:
> On Sat, Nov 15, 2025, at 15:41, Edmond Dantes wrote: > > Hello. > > > Based on the conversation so far, I’d imagine the list to look something > like: > > Yes, that’s absolutely correct. When a programmer uses an operation > that would normally block the entire thread, control is handed over to > the Scheduler instead. > The suspend function is called inside all of these operations. > > > I think that "normally" is doing a lot of work here. fwrite() can block, > but often doesn’t. file_get_contents() is usually instant for local files > but can take seconds on NFS or with an HTTP URL. An array_map() *always* > blocks the thread but should *never* suspend. > > Without very clear rules, it becomes impossible to reason about what’ll > suspend and what won’t. > > > > If that’s the intended model, it’d help to have that spelled out > directly; it makes it immediately clear which functions can or will suspend > and prevents surprises. > > In the Async implementation, it will be specified which functions are > supported. > > > This is exactly the kind of thing that needs to be in the RFC itself. > Relying on "the implementation will document it" creates an unstable > contract. > > Even something simple like: > > - if it can perform network IO > - if it can perform file/stream IO > - if it can sleep or wait on timers > None of the above is part is this RFC so why is this being discussed. Any of the changes to stream layer and extensions will require special RFC and mainly clean implementation. We will need to carefully consider where the suspension is going to be done. I think if there are parts of the RFC that mention IO, it should be removed here. I think this RFC should also remove any mention of reactor as it's irrelevant for this. Kind regards, Jakub
