Description
Computers, consoles, and phones all have more than one CPU core these days. But aside from audio/video decoding, all of love's own internal code is singlethreaded. We do have APIs to run Lua code in multiple OS threads, but because each thread needs its own Lua instance it takes work to use efficiently in a lot of situations - independent heavy algorithm processing and asset loading are the two easiest ways to use love's threads right now.
Most modern game engines have an integrated job/task system they use with a thread pool, to parallelize their own work (for example render command generation or physics simulation) and often to parallelize game code, all in a fairly simple manner.
It'd be nice to have something like that in love - maybe just for internal use to start (if good uses can be found) since more infrastructure and profiling work would need to be done to make it really solid in Lua code. In particular it becomes a lot easier to know how to use and misuse a job/task system when there's a way to visualize the different parts of a frame and what job threads are doing in a given section, and there would be details to figure out for keeping jobified Lua functions side effect free in a given job thread.
enkiTS seems like a solid library for the base of this sort of thing.