> Yeah we are actually planning better API for this supporting epoll and kqueu which is long over due. There are other use cases for this so hopefully it will get prioritised soon. Oh, it would be absolutely great if PHP used a better abstraction for I/O waiting!
> You could still achieve this in extensions. But if you really wanted to have some main part, then it should rather go to main/ like streams and other similar stuff. Of course, this will need some thought. I have got some additional feedback from our discussion that we just had > with the PHP foundation devs. *It was that it looks like an async/await > implementation with fiber switching which is something that was explicitly > decided not to be done in fibers RFC* - https://wiki.php.net/rfc/fibers (read > FAQ). The reasoning was that this should be done in user space. So you > should properly describe in the RFC what this offers compare to user space > variants (revolt/react/amp). There were also some concerns that it would > makes things harder to debug in internal implementation so this should be > also addressed in the RFC. It should be noted that Fibers RFC did not > preclude introduction of such extensions to the core but you will likely > need describe it in the RFC and show that there are good reasons to include. Unfortunately, I don’t know much about what happened during the adoption of Fibers, but I remember that the situation was not ideal. I don’t know why that decision was made. For me, as a developer, the ultimate criterion is the code itself. If a solution makes the code better, simpler, and reduces the number of lines, then it’s a good solution. If a solution forces developers to repeatedly write the same boilerplate code, including entire MySQL/PostgreSQL drivers, then I can’t consider it a rational decision from a development perspective—though, of course, there could be other reasons, such as financial constraints or lack of resources. Or look at Swoole—it has to override dozens of PHP functions. Even worse, it recently started literally copying entire extensions just for a few lines of code... This does not look like a "good solution." AMPHP and Revolt are talented projects, but they are not part of the language itself. This means that PHP extensions cannot call user-mode code and rely on it as a standard, unlike how Rust extensions do. Of course, from C, you can call any user-mode function, but that doesn't seem like the right approach. Especially since PHP is a high-level language, which imposes a responsibility for consistency in its paradigm. Regarding debugging—over the past three years, there have been no debugging issues with AMPHP. Consequently, there shouldn’t be any, since this project does not modify the Fiber mechanism itself. It only extends it to make the tool more complete and fully functional. And this is precisely the main reason why I’m writing these lines. As a PHP developer, I see that the language is not truly complete when it comes to concurrent programming, and I am genuinely surprised that this has not been addressed yet. How did this happen? Have a nice day! Ed.
