On Sat, Nov 15, 2025, at 22:40, Jakub Zelenka wrote: > > > 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
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
