On Sat, Nov 15, 2025 at 10:19 PM Rob Landers <[email protected]> wrote:
> > > 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. > But this is hard to know exactly. Also there will be always 3rd extensions that can block so we will need to do it piece by piece. You can just take it that ideally everything that can block would be suspendable . The first candidate is surely stream internall poll that is used for stream IO in various places and could handles most suspensions including in mysqlnd. Then curl and sockets would be probably added. There are various other bits already present in Edmonds PoC but we will need to consider them one by one. In other words, we can't really know that until we have some base pieces merged (this RFC) and there is acceptable implementation that can be merged for those parts. Kind regards, Jakub
