On Sat, Nov 15, 2025, at 22:17, Jakub Zelenka wrote: > 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.
My point is that it *should* be a part of the RFC. — Rob
