Re: Re: PHP True Async RFC Stage 5

On Sat, Nov 15, 2025, at 22:17, Jakub Zelenka wrote: > Hi, > > On Sat, Nov 15, 2025 at 8:56 PM Rob Landers <rob@bottled.codes> 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. ý]O·’)j >> ô¾•qÄ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