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
- if it awaits a `FutureLike`
- if it calls `suspend()`
This would then create a stable baseline and require an RFC to change the
rules, forcing people to think through BC breakages and ecosystem impact.
>
> > I also think the RFC needs at least minimal wording about scheduler
> > guarantees, even if the details are implementation-specific.
> The Scheduler guarantees that a coroutine will be invoked if it is in the
> queue.
That’s not quite enough. The order really matters. Different schedulers produce
different observable results.
For example:
function step(string $name, string $msg) {
echo "$name: $msg\n";
suspend();
}
spawn(function() { step("A", "1"); step("A", "2"); step("A", "3"); });
spawn(function() { step("B", "1"); step("B", "2"); step("B", "3"); });
spawn(function() { step("C", "1"); step("C", "2"); step("C", "3"); });
Under different scheduling strategies you get different, but stable patterns.
Consider FIFO or round-robin, run-to-suspend:
A: 1
B: 1
C: 1
A: 2
B: 2
Cl: 2
A: 3
B: 3
C: 3
But with a stack-like or LIFO strategy, running-to-suspend:
A: 1
B: 1
C: 1
C: 2
C: 3
B: 2
B: 3
A: 2
A: 3
Both are valid, but are important to *know* which one is implemented, and if
someone wants to replace the scheduler, they also need to ensure they guarantee
this behaviour.
>
> > For example, is the scheduler run-to-suspend? FIFO or round-robin wakeup?
> > And non-preemptive behaviour only appears here in the thread. It isn’t
> > mentioned in the RFC itself.
>
> In Go, for example, when it was still cooperative, these details were
> also not part of any public contract. The only guarantee Go provided
> was that a coroutine would not be interrupted arbitrarily. The same
> applies to this RFC: coroutines are interrupted only at designated
> suspension points.
> However, neither Go nor any other language exposes the internal
> details of the Scheduler as part of a public contract, because those
> details may change without notice.
Go did document these details during its cooperative era, including exactly
where goroutines might yield. Unfortunately, I can’t find a link to
documentation that old. I did come across the old design docs that might shed
some light on how things worked back then: https://go.dev/wiki/DesignDocuments
The key point is that Go made cooperative scheduling predictable enough that
developers could write performant code without guessing.
>
> > That’s important for people writing long, CPU-bound loops, since nothing
> > will interrupt them unless they explicitly yield.
> Hypothetically, in the future it may become possible to interrupt
> loops, just like Go eventually did. This would likely require an
> additional RFC. PHP does have the ability to interrupt a loop at any
> point, but most likely only for terminating execution.
> This RFC does nothing of the sort.
My concern isn’t the lack of loop preemption. My concern is that the RFC never
*says* CPU loops *don’t yield.* If it isn’t stated explicitly, it won’t be
documented, and users will discover it the hard way. That’s exactly the sort of
footgun we should avoid at the language level.
> > Lastly, cancellation during a syscall is still unclear. If a coroutine is
> > cancelled while something like fwrite() or a DB write is in progress, what
> > should happen?
> > Does fwrite() still return the number of bytes written? Does it throw? For
> > write-operations in particular, this affects whether applications can
> > maintain a consistent state.
>
> If the write operation is interrupted, the function will return an
> error according to its contract. In this case, it will return false.
`fwrite()` almost never returns `false`, it returns "bytes written OR false".
Partial successful writes are normal and extremely common. So, cancellation
*does* change the behaviour unless this is spelled out very carefully so
calling code can recover appropriately.
>
> > Clarifying these points would really help people understand how to reason
> > about concurrency with this API.
>
> This is described in the document.
I may be missing something, but I don’t see this spelled out anywhere in the
RFC.
> There is, of course, a nuance regarding extended error descriptions,
> but at the moment no such changes are planned.
That’s fine, but then do you expect the RFC to pass as-is? Right now, without
suspension rules, scheduler guarantees, defined syscall-cancellation semantics,
it’s tough to evaluate the correctness and performance implications. Leaving
some of the most important aspects as an "implementation detail" seems like
asking for trouble.
— Rob
