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
