Re: PHP True Async

On Fri, Feb 14, 2025, at 16:18, Edmond Dantes wrote: > > 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. > > >> I'm reminded of Rowan's comment here: Why did fibers get added to php core over something more fleshed out like swoole? - Externals <https://externals.io/message/121291#121315> (https://externals.io/message/121291#121315) > Sometimes the answer to "why doesn't X do Y?" is just "because > nobody's stepped forward to implement it yet"; sometimes it's "nobody's > worked out how to do it without breaking Z"; in which case, feel free to volunteer that time, > or solve that issue. But, yes, sometimes it's "because we had a long and tiring debate, > and ended up with a compromise that nobody really likes"; or "because the lack of official > leadership and a relatively high turnover of contributors makes us pretty bad at longer-term > planning". It pretty much sums it up (also, you can always search the mailing list archives for previous discussions on these topics). — Rob