Hi Bob, On Sat, Nov 22, 2025 at 5:50 AM Bob Weinand <[email protected]> wrote:
> Hey Jakub, > On 21.11.2025 12:29:16, Jakub Zelenka wrote: > > Hi, > > I think you seriously underestimate impact of this in the current PHP code > bases where many applications depend on global state. Especially the legacy > ones but even the most popular ones. Just look into WordPress which use > global state extensively. 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. Don't forget that other code don't have control over the plugin and > it might not even know that async is used there. So I'm not sure if this > design is compatible with WordPress and similar applications where global > state is used extensively. If that's the case, it's of course a problem > because those applications (well WordPress on its own in fact) compose the > majority of PHP users so introducing something that would have potential to > break its code would limit usability of the whole feature and could even > lead to loosing more users that we could gain from introducing this feature. > > So I think it will need to find some solution that will prevent this from > happening. I guess there might be few options > > 1. Disallow suspension of the main sync code which is effectively some > sort of colouring. > 2. Preventing access to globals from coroutine which I'm not sure is even > fully doable from the engine PoV - it would mean some sort of different > execution mode that could not use globals (e.g. global keyword and calling > some functions that change global state). It would need channels for > communications between coroutines. The advantage of such model would be > possibility to combine it with threads in the future but I could imagine it > could still lead to some subtle issue for years as there is internal global > state as well that can lead to some surprises. But maybe that would be > worth it. > > I think you seriously misunderstand this. > > Async does not allow you to introduce some effects from the outside. You > have to actively opt-in to running stuff in parallel. > But you don't have to opt in into it in this current form. If some external plugin calls spawn (without await), then it can suspend other plugins (that didn't opt in to it) in places where it wasn't expected. > The problematic part, is, when you call code inside of coroutines, which > is not safe to be run in parallel with other code. > > I.e. if you start writing code like `await([new Coroutine(fn() => > not_safe_to_run_twice()), new Coroutine(fn() => not_safe_to_run_twice())])` > (pseudo code). Where not_safe_to_run_twice() shares some context. > > Well if you call await, you should be safe but that's not requirement here. You can just spawn coroutine and main functions continues the flow to other plugins that didn't opt in to async. So, when you write async code, you have to *know* that the called code is > allowed to run in parallel with any other code which you explicitly chose > to run in parallel with it. E.g. if you'd run two wordpress functions which > don't have side-effects (not even to internal state), then you're perfectly > fine doing that. If you run wordpress functions in parallel which may jump > back to the scheduler during its operation and leave the internal state in > some intermittently invalid form, then yes, then you have a problem. > I'm not saying that is not possible to write safe code. This would be perfectly possible and recommended, of course. The problem is that it doesn't prohibit writing unsafe code in any way. > But if your goal is to just do a localized parallelized operation which > you know is safe to run in parallel - e.g. some image processing and > storing some stuff in the database, within your wordpress plugin, that's > absolutely fine. It won't break anything. > Not sure if you worked with WordPress but if you want to query something, it is often done through $wp_query global so it might actually not be always safe if there is some IO done in between building the query. > Essentially: Just don't call stuff in parallel which you don't know is > safe to be called in parallel and you're golden. > That's, of course, correct advise but I'm not sure you realise that if those rules are not somehow enforced, it will be most likely get ignored and lead to problems that many people are worried about. Also it might not be immediately obvious that something is safe because the change of state might happen indirectly and be deeply nested. Kind regards, Jakub
