Hello all. Some of these questions sound familiar. Let’s try to sort them out.
> If I have a tight loop processing data in memory (no I/O), will it monopolise > the coroutine scheduler? Do I need to manually insert suspend() calls? How do > I know when and where? A coroutine must yield control on its own. If it keeps it through an endless loop, then it will be the only one running. > The RFC suggests that existing PHP functions won’t automatically be > non-blocking. So which will? Is there a way to identify suspension points at > the language/API level? The RFC does not say that. PHP I/O functions automatically become non-blocking relative to the whole process. In other words, an I/O function calls suspend() on its own when needed. The programmer writes code exactly as before, under the illusion that operations are executed one after another. > Performance implications: Without knowing where suspensions occur, how do > developers avoid either: In most cases, this is not the developer’s concern. Situations where performance is critical should be handled with dedicated tools. A PHP developer should not have to drop down to the C level. Properly designed abstractions must provide the required performance. I can already anticipate the question: but a developer could write something like “for i < 10000 suspend” or something similar. The answer is this: a developer must know how to use abstractions. As always. Everywhere. In any area of programming. It’s just as important as respecting proper layering in code. Provided that PHP does not try to play the role of a C-level language (there have already been such attempts, and they keep resurfacing), and does not try to play a web server or a database system. For most web scenarios, the current approach is more than sufficient. This has been proven by Swoole, which has been on the market for many years. Therefore, performance questions are outside the scope of this RFC. As for the concurrency model, let me remind you that Go has true multitasking. Goroutines in Go, although they have a “synthetic” stack. But you already know all this well. This RFC and its implementation describe coroutines in a single thread. That is very far from what Go provides. There is no preemptive multitasking in this RFC because it is completely unrelated. This RFC and its implementation provide cooperative concurrency in a single thread, where coroutine code yields control on its own. Why was this model chosen? The simple answer is: because it is the only one that can realistically be implemented within a finite timeframe. Any more questions? -- Ed
