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.
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.
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.
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.
Essentially: Just don't call stuff in parallel which you don't know is
safe to be called in parallel and you're golden.
Bob
