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. > 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. > 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. > 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. > 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. > 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. > Clarifying these points would really help people understand how to reason > about concurrency with this API. This is described in the document. There is, of course, a nuance regarding extended error descriptions, but at the moment no such changes are planned.
