In other words, it'd be only useful for auxiliary computations that are entirely independent from the game state, depending only on the inputs you give to it.ĭon't get me wrong, I'm all for having the option, I'm just not sure how they're going to pull it off.Ĭlick to expand.Same answer, yes and no. You most definitely would have to jump through weird hoops to send data between threads (channels?), and it's very likely that only one thread would have access to the engine's API. Which, in practice, translates to some ergonomic concessions when trying to use them. Even Lua doesn't really support multithreading, though there are some extensions and libraries that add such support, but even then, they come with some big caveats AFAIK.
I also wasn't so much referring to the potential of the users mis-using the API, but rather the inherent challenges associated with providing a thread-safe engine API. Lua does have one in the form of coroutines already. If you simply want concurrent running tasks, then a single-threaded asynchronous model is preferable. I can't really think of many scenarios where using multiple threads would be a requirement, unless you're doing something really computationally heavy (in which case, perhaps you should be making your own game instead anyway.). In my personal experience with modding, even the most "demanding" mods don't really need to tap into multi-threading.
0 kommentar(er)
