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.
— Rob