[WMCoolmon]

Hmm, fancy new board theme here.

I had some text here about the history of multithreading, but a back/forward slip leads me to rewrite it in more concise form:

• Threading within the engine is generally very complicated and effectively infeasible (but not impossible)
• Threading the Lua engine with the fs2_open core engine is still about as problematic as the first one

However, threading Lua scripts (running multiple ones at once while the engine core blocks) has three nice properties:

• The fs2_open internal Lua API uses a single function to determine access to all API functions and variables
• The Lua API is written (with a few exceptions) to be as robust as hell provided you don't risk divide-by-zero, and does a lot of internal error checking every time you call a function or variable.
• Implementing synchronization abilities and then allowing modders to choose to deal with it in new scripts is easier than trying to multithread a complicated ginormous internal system.

Broad overview of the implementation idea:

Step 1: Put a mutex in ade_index_handler() that gets locked at the start of the function and unlocked once it finishes. This will force atomicity of FS2Open core operations by only allowing one FS2Open Lua API function (or variable) to be called, read, or modified at once.

Step 2: Extend the Lua API to have some kind of threading library providing the ability to create a thread running a Lua function, some messaging/barrier/mutex stuff, etc.

The downside to this would be that there'd be no real benefit if all you were doing was making calls to the FS2Open API. But if you were doing a lot of pure-Lua calculations that took a substantial amount of time, you could multithread those calculations whilst running the calls to update the FS2 objects in another thread. Or just have two threads simultaneously running calculations.

Step 2 might be as simple as using Lua Lanes. Has anyone tried Lanes with FS2Open?

Regardless, this seems very doable in a short amount of time. Except for the expected unplanned complications that typically crop up.

[Nuke]

ive never really had a need to be able to do multithreading with the lua system. there are some theoretical applications that ive been thinking about that could benefit from mt. one of which is communicating with devices / applications over serial connections / named pipes, where data would need to be buffered as it arrives or send data at a specific time. my main goal is communication between the game and external hardware and software. such as driving a full motion simulator, or controls for home-brew cockpit simulators (or a combination of the two), without having to mess with the fs2 engine at all, using some scripts.

im sure if mt support is added it will only be a matter of time before it gets used. as scripts get larger performance becomes a major issue, so if some of the script can be run on another core that would be awesome. though i can think of very few situations right now (except for maybe the above) which it would be critical to have.