2026-04-06T14:04:12  <OpenMW-bridge> <heilkitty811> Guise, this may be a really dumb questions, but can't we already make the engine run Lua scripts from different contexts in separate threads? Scripts from different contexts are supposed to message each other via events anyway. Or would that be too much to rewrite, when proper multiplayer support is gonna be introduced in 2090?
2026-04-06T15:12:13  <OpenMW-bridge> <anyoldname3> Someone else more familiar with our scripting system might tell me I'm wrong, but I think Lua scripts already run on different threads from a thread pool, so there's already parallelism.
2026-04-06T15:32:50  <OpenMW-bridge> <dreamhour> We have two separate Lua evaluation steps each frame. The sync one runs in the beginning of the frame and blocks further frame pipeline. That's why it's recommended to avoid using onFrame handlers if possible. 2nd evaluation of Lua scripts happen in separate thread parallel with culling of current frame. Culling usually takes significant time so 2nd part of Lua evaluation is "free". But the cost of this parallel
2026-04-06T15:32:51  <OpenMW-bridge> processing is paid in API complexity - we have all that (usually unmarked) async/delayed lua actions to mutate engine state, which are applied only on the next frame.
2026-04-06T15:35:23  <OpenMW-bridge> <dreamhour> https://cdn.discordapp.com/attachments/1230951723443552256/1490736687838662696/Screenshot_20260301_234906.png?ex=69d5243a&is=69d3d2ba&hm=18ac27db1706a31a06c55906d01bd0e8be3a177c7ba1ce46cdaeff1780f4b785&
2026-04-06T15:42:32  <OpenMW-bridge> <heilkitty811> But still, different contexts could be run in different thread. Or I'm wrong and that would require proper serialization? Or wouldn't really increase performance?
2026-04-06T15:44:03  <OpenMW-bridge> <assumeru> There's room for further parallelization, yes
2026-04-06T15:46:02  <OpenMW-bridge> <dreamhour> Parallelizing Lua sync might help, but I don't know how hard it would be to ensure thread safety in that case
2026-04-06T15:55:16  <OpenMW-bridge> <dreamhour> There is also a room for improvement with out approach to LuaJIT optimization. We interfere with it in two major ways - by making a lot of C++ function calls, which it can't optimize. And also by running each script in a separate sandbox. Because of that, JIT can't see that the same function is called in different contexts, and JIT has to repeat its work in each of them.