Avoid duplicated reading RPN code execution across multiple clients

[cpuwolf]

Description:

This PR introduces a performance enhancement for handling multiple clients subscribing to identical SimVars. Currently, if multiple clients add the same RPN code (e.g., via MF.SimVars.Add), the WASM module executes the code redundantly for every instance within a single frame.

Changes:

Implemented a "calculate once, distribute to many" logic. The WASM module will now detect duplicate RPN codes and execute them only once per frame.
Introduced a new ReadRPNCode structure to manage the mapping of single code executions to multiple SimVars/StringSimVars.

//RPN code execution for reading values in every frame
struct ReadRPNCode {
	std::string Code;
	int RetType; //RetType: 0:float 1:integer 2:string
	std::vector<SimVar> SimVars;
	std::vector<StringSimVar> StringSimVars;
};

Stability:

This patch is highly stable and production-ready. It has been deployed to over 1,000 customers for more than a year with no reported issues.

[Michuru]

Not sure if this counts as useful data or just noise, but I've hit two crashes that line up closely with the scenario this PR describes, so I figured I'd drop the details here.

I run MSFS 2024 with SPAD.neXt driving a Stream Deck setup, and MobiFlight's WASM module handles the L:Var and B:Var bridging for that. Alongside SPAD.neXt there are usually another 15 to 19 SimConnect clients connected at the same time: GSX Pro, ChasePlane, Navigraph's charts and SimBrief apps, FenixBootstrapper, PMDG's Couatl engine, Volanta, TDS GTNXi. Quite a lot running at once. Most of these stay connected no matter which aircraft is loaded. Even a flight that has nothing to do with PMDG or Fenix still carries their bridges along for the ride.

Twice now the whole sim has locked up on me and I've had to force-close it. MSFS's own crash reporter caught both, one on September 2nd flying a Fenix A321 and the other on September 19th flying an A2A Aerostar 600. Both reports classify the failure the same way: Where="HangDetector", Code=0xC0000194, the Windows status for a detected deadlock. MobiFlightWasmModule.wasm was resident both times, at exactly 268566528 bytes on the nose.

No smoking gun here. I can't say MobiFlight was the client that deadlocked. The callstack section in both reports came back empty, so the hang detector never managed to walk the stuck thread. It could just as easily be one of the other dozen clients, or some pairing between two of them fighting over the same lock. But the setup matches what this PR is aimed at closely enough, several clients pulling the same SimVars every frame, that it felt worth flagging here instead of opening a vague new issue with no callstack behind it.

[cpuwolf]

Yes, the PR is meant to optimize multiple clients, but as far as I know, there isn’t any real-world usage of MF WASM yet—aside from my own project:

https://gitee.com/FlyLuaIo/flyluaiosc/releases#release-0.4rc2

I completely agree with you. When I first started FlyLuaIoSc, I considered building my own WASM module, but after researching it and stepping back to look at the bigger picture from MSFS’s perspective, I realized that creating a new WASM module would eat up MSFS performance. So in the end, I decided to reuse MF WASM as just another client, sharing it with the MF connector.