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.
