- Issue created by @kingdutch
This is postponed on 🌱 Adopt the Revolt event loop for async task orchestration Active since an async primitives library is only useful if there's an event loop we're managing things on. However, it's posted already because the two decisions are separate.
Whether Drupal should also adopt an "async tools" library on top of that is a bit harder for me to say. I still don't quite understand why Drupal can not adopt e.g. amphp/mysql as its async MySQL solution, rather than building our own. Especially now that Fibers have removed the need to transform all the ways of how we call the function, but allow more easy transparent suspension. (This was definitely different 6-18 months ago though)
The biggest reason would be that "not invented here" also means "not maintained here" which means for an important aspect of Drupal we'd be reliant on, and at the whims of, a third party. Given how big of an aspect our database system is on Drupal I could see that being a problem.
Not using a library for Async primitives is also less of a problem. Most of these libraries focus on subsystems of some I/O (e.g. "MySQL", or "Redis", or "RabbitMQ") and as long as they use the same event loop those different implementations can be scheduled along side one another.
I think there's a case to be made for Drupal to create some of its own scheduling primitives on top of Revolt's Event Loop to do things like "Only execute this task if there's nothing else to do" or "wait for all of these tasks to be done". I do expect a lot of these to be duplicating (or very similar) than those provided in amphp/amp which is exactly such a library, requiring nothing beyond the Revolt event loop. So there's also the option of adopting Amp and filling in the gaps that we might have.
I think the most important accelerator for asynchronous tasks in Drupal is the adoption of the Revolt event loop, because it suddenly provides an entire async ecosystem for contrib to use. However, there's definitely overlap in what Amphp/ReactPHP offer and if the contrib Redis module settles on Amphp and the contrib RabbitMQ client settle on ReactPHP, then a lot of projects might have both primitives in their projects. So there is a benefit for Drupal to create a preference (or force contrib to re-invent some wheels).
In the category of DIY vs use-something-existing though I would argue that Revolt and amphp/amp:v3 are probably the most "How to fiber" libraries currently out there by the very fact that the maintainers of Amp are also the authors of the Fibers RFC (Aaron Piotrowski & Niklas Keller).
Postponed
11.0 🔥
Last updated
