On Fri, 21 Nov 2025 at 09:08 Edmond Dantes <[email protected]> wrote:
> Hello > > > I think you seriously underestimate impact of this in the current PHP > code bases where many applications depend on global state. > Do I really look like someone who could underestimate memory-related > issues? :) > > > Now imagine that some popular plugin decides to use async which change > some of its globals (like $post or $wp_query) during the suspension of the > main code. I would assume this could horribly break things. > Or for example, you run an old WordPress on the new PHP 8.5 and > everything breaks. Is that a reason not to release new PHP versions? > No, I’m not joking. That’s literally the essence of the argument. If > something might break, then we shouldn’t do it? > > This is a common story. There is a framework that is adapted to a > technology, and there is a framework or library that is not adapted to > it. > If a framework is not adapted, you simply won’t be able to use the > technology. So why is this considered a problem? > However, inside WordPress you will still be able to use coroutines as > long as you don’t call WP functions that aren’t adapted. You can. So > why is this a problem? > > I can use AMPHP inside WordPress and break WP. > So does that mean we must urgently remove Fiber from the language? > Because AMPHP uses Fiber, and AMPHP implements coroutines. And > coroutines break WordPress. > Asynchrony already exists in PHP. You can write async code today. > Which means you can already do all the “horrors” you’re talking about. > TrueAsync cannot change that. And no one else can change it either. > So why is this being treated as an argument against it? > > > Don't forget that other code don't have control over the plugin and it > might not even know that async is used there. > Exactly. This means that right now I can use Fiber plus select() to > write async code and break WordPress. > And I can also write a plugin that divides by zero and crashes > WordPress, and WordPress won’t know anything about it. > > > So I'm not sure if this design is compatible with WordPress > > Yes, WordPress is not compatible with asynchrony. I’ll emphasize > again. This is not about TrueAsync specifically. This is about > asynchrony itself. Yes, WordPress and Laravel are not compatible with > concurrent execution. That’s true. > But are you **really suggesting** that because of this, all other > applications should be denied the ability to use it? > Moreover, would you deny WordPress itself the possibility of > supporting asynchrony in future? After all, WordPress can be > refactored. It’s not carved in stone. > > Wouldn’t WordPress benefit from the performance improvements that > async provides? > Wouldn’t WordPress plugins benefit from being able to actively > communicate with microservices and deliver the fastest possible > responses to JavaScript? > > Is this feature really something nobody needs? If yes, then I have no > further questions. > > Async is needed to increase throughput. That’s the purpose. If a PHP > project doesn’t need it, it doesn’t have to use it. That’s fine. But > there are PHP projects that do need it. The point you’re trying to make here is very clouded for me. Although you can use AMPHP to break Wordpress, there is an extensive process of “opt-in” for you to do that and it doesn’t happen naturally, accidentally or unintentionally. You’ll have to setup a plugin that requires AMPHP and write some code that will inadvertently break and never really see the light of day. Now there’s 2 possibilities for us to go from here: my understanding of the most basic concept of TrueAsync is still wrong OR the comparison you’re trying to make isn’t relevant. My understanding is that if this RFC were to be implemented as-is, you would be able to open any PHP file and write \Async\spawn() and: nothing would blow up but any code inside the project that touches global state could silently misbehave. Is this not true? My understanding of AMPHP is that things only become async if you explicitly run AMPHP as your web server. It either has no effect if your application is running Apache + mod_php OR your application 100% breaks with nothing getting executed at all. Is this not true? I know you're tired of debating very basic things, but from the conversation on the list, I think I'm not the only one confused by this. We did talk about our desire to have Async on PHP-FPM and as far as I remember you mentioned it not being very useful, but that it would be possible nonetheless. This is the a core principle that matters a lot. Here is a very simple hypothetical: Suppose I run a website and I have very little understanding of PHP, but I know the basics. Every Monday I run `composer update`, do a little testing and deploy the website. Suppose next Monday when I run `composer update` one of my dependencies (Package A) starts to pull in AMPHP as its nested dependency. When I try to open my website locally it will either have everything broken or it will just work regularly and nothing will be running async. There is no other option. Now suppose the same example but with PHP 9 + TrueAsync. I do `composer update` one day and test my home page and it works. But deeply nested somewhere there is a feature that will use Package A which then spawns a coroutine and leads to my global state code behaving weirdly. It's not a fatal error. It's not very clear at all to me that something changed, but now my array indexes are triggering DB updates out of order. If my assumptions about TrueAsync are completely wrong and that's not possible at all, I think that's not clear for everyone. But if my assumptions are right, then your comparison with AMPHP is not the same thing.
