Adopt the Revolt event loop for async task orchestration

We should add a dependency evaluation to the issue summary, it almost there already, just release cycle and security policy I think: https://www.drupal.org/about/core/policies/core-dependency-policies/depe... →

I still have not fully grasped the benefit of the central event loop vs. for example adding a trait to cover the current raw Fibers implementation (which could then handle sleeping, suspending to any parent Fiber in one place etc. centrally, but would still keep the management of each loop local). For me at least, it would be useful to see a conversion of the manual Fibers loops in core, we also have some examples of suspension in the cache prewarming/stampede issue (if not actual async anywhere yet).

I've filled out the dependency evaluation.

I still have not fully grasped the benefit of the central event loop vs. for example adding a trait to cover the current raw Fibers implementation (which could then handle sleeping, suspending to any parent Fiber in one place etc. centrally, but would still keep the management of each loop local). For me at least, it would be useful to see a conversion of the manual Fibers loops in core, we also have some examples of suspension in the cache prewarming/stampede issue (if not actual async anywhere yet).

I emailed Aaron with this question and he replied with

Drupal absolutely should use the Revolt event loop. The entire reason Revolt exists is to avoid fragmentation of the event loop component among PHP libraries which want to run asynchronous tasks. The event loop essentially becomes a part of the runtime – you cannot mix multiple event loops in the same application because only one can be running at a time. We talk a bit more about this at https://revolt.run/fundamentals.

Using a propriety loop which schedules fibers would make Drupal incompatible with any library using a different fiber scheduler – i.e. any library using Revolt.

AMPHP might also be useful for some of the primitives it provides, such as Futures and Cancellations, as well as some of the lower-level helper libraries like amphp/pipeline. Note though using AMPHP would be completely optional – Drupal could implement it's own promises/futures, etc. and still be compatible with AMPHP so long as it was using Revolt to schedule events.

Revolt is flexible and un-opinionated, making it easy to create new fibers, use timers, and wait for I/O. Check out the docs at https://revolt.run and let me know if I can provide any additional examples or assistance.

The relevant part of that fundamentals document (in case it changes and someone is reading this in 2025 👋):

Every application making use of cooperative multitasking can only have one scheduler. It doesn’t make sense to have two event loops running at the same time, as they would just have to schedule each other in a busy waiting manner, wasting CPU cycles.

Revolt provides global access to the scheduler using methods on the Revolt\EventLoop class. On the first use of the class, it will automatically create the best available driver. Revolt\EventLoop::setDriver() can be used to set a custom driver.

To add to that personally I think with the initial Fiber code that was added we've already seen some challenges with CPU spinlocking. To me this feels very much like a problem where the initial case is trivial and as we adopt Fibers more we'll find more of these edge cases (oh we'd like to just let the system sleep until I/O comes back if there's nothing else to do). We'd then be solving exactly the problems that Revolt has already solved, but doing so in a way not compatible with other async code in the ecosystem.

No current security policy published.

Can we ask the maintainers if they are willing to publish a security policy? Given that this is a low level runtime dependency it seems quite important that if there is a security issue the maintainers are prepared to fix it within a reasonable timescale.

I've opened an issue with the request: https://github.com/revoltphp/event-loop/issues/87

To add to that personally I think with the initial Fiber code that was added we've already seen some challenges with CPU spinlocking. To me this feels very much like a problem where the initial case is trivial and as we adopt Fibers more we'll find more of these edge cases (oh we'd like to just let the system sleep until I/O comes back if there's nothing else to do). We'd then be solving exactly the problems that Revolt has already solved, but doing so in a way not compatible with other async code in the ecosystem.

I think we could solve some of that by moving the individual loops to use a helper class
so there's less repetition, if that was the only reason I'm not sure it would be worth it, but the interoperability arguments here are quite strong so that is pushing me over from neutral/on the fence towards pro-adoption of Revolt at the moment.

Issue fiixed https://github.com/revoltphp/event-loop/issues/87

Updated the remaining tasks. I've created a child issue to add the dependency to the composer.json: 📌 Add revoltphp/event-loop dependency to core Active which now also contains the dependency evaluation.

Updated the issue summary with the remaining tasks to show tasks in progress. At least with the current proposed implementations it appears no work for PHPUnit is needed. If tests want to test something specifically that doesn't block the main thread at some point then they'll have to run EventLoop::run() in the test themselves.