Re: Re: PHP True Async RFC Stage 5

On Sat, Nov 15, 2025, at 22:40, Jakub Zelenka wrote: > > > On Sat, Nov 15, 2025 at 10:19 PM Rob Landers <rob@bottled.codes> wrote: >> __ >> >> >> 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. >>>> 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 I guess my main thing is that this RFC should only cover coroutine machinery: it should *not* promise "transparent async" or "code that works exactly the same" *OR *if it wants to make those claims, it should actually demonstrate *how* instead of hand-waving everything as an "implementation detail" when none of those claims can actually be validated without those details. — Rob