No X-Plane SDK calls from outside main thread

[TwinFan]

Describe the bug Calling X-Plane SDK functions from outside XP's main thread is and has always been forbidden. A recent crash unveiled that there might be overlooked examples.

Ben Supnik in a mail also very clearly stated that restrictions might be enforced even more in future versions:

Thanks for looking into this - the main thread rule applies to every AI call, so please just make sure that everything gets deferred back to the main thread even loggign calls. The sim will only kill you for some calls now but it will be all calls in the future, matching the API spec.

In the above mentioned case, calls to SHOW_MSG were handled by deferring creation of the message area window.

Todo

• [X] Review all functions called from network and calculation threads. Don't forget temporary threads spawned by std::async and friends:
  • LTChannel.cpp
    • [X] FDMainThread
      • [x] Review all channels' code, which is called through FetchAllData, ProcessFetchedData, and DoDisabledProcessing
      • [x] TO CHANGE: Calls dataRefs.GetViewPos(), which uses XPLMReadCameraPosition and XPLMLocalToWorld
    • [x] CalcPosThread
  • LTForeFlight.cpp
    • [x] ForeFlightSender::thrUdpSender
  • LTRealTraffic.cpp
    • [x] RealTrafficConnection::thrTcpServer
    • [x] RealTrafficConnection::thrUdpListener
  • LTADSBEx.cpp
    • [x] DoTestADSBExAPIKey
  • LiveTraffic.cpp / LTVersion.cpp
    • [x] FetchXPlaneOrgVersion
  • LTApt.cpp
    • [x] AsyncReadApt
• [x] Follow though calls to XPMP2 functions...while rare also they might call X-Plane SDK functions.

To be changed centrally:

• [x] Also handle LOG_MSG centrally by keeping a backlog of texts to write out to XPLMDebugString. Should be combined with message handling in the upcoming information window #121 as that will require a list of message anyway. Keep a flag in there if it had been written out to Log.txt already or not.
• [x] Probably need our own regular flight loop callback then, ie. the current call every second would need to be spiced up.
• [X] XPMP2::Aircraft::SetInvalid() subsequently calls XPLMDestroyInstance (this is currently already causing crashes).
  • Handled now by XPMP2::Aircraft::DestroyInstances setting a flag if not in main thread.
  • [x] Test this.
• [x] DataRefs::GetSimTime() makes calls to XPLMGetData... but only if using historic data (ie. not urgent, historic data not currently supported)

Technical Info:

• OS: all
• X-Plane version: all
• LiveTraffic version: v2.07

Additional Info Blog post on thread-validation in Beta 14

[TwinFan]

Aircraft invalidation happens from the "CalcPosThread" (LTFlightData.cpp:657 in LTFlightData::DataCleansing()), which can now crash XP. Has been reported twice in the support forum (one, two) and looks like this in the log:

1:54:40.620 LiveTraffic DEBUG LTFlightData.cpp:1534/IsPosOK: AB6784 N834DC: Invalid vector <h 282,   108m @ -83kt, -nan(ind)ft/m> with headingDiff = 151
1:54:40.620 LiveTraffic DEBUG LTFlightData.cpp:1534/IsPosOK: AB6784 N834DC: Invalid vector <h 139,   801m @ 173kt, 1912ft/m> with headingDiff = -144
1:54:40.620    LT/XPMP2 ERROR Aircraft.cpp:615/SetInvalid: Aircraft 0xAB6784 set INVALID
1:54:40.620 E/SYS: THREAD FATAL ASSERT: rel_assert Error! Possibly an out of range vector! Attach the debugger and see who called this!
1:54:40.620 E/SYS: THREAD FATAL ASSERT: !THREAD_is_inited() || THREAD_is_main_thread()
1:54:40.620 E/SYS: THREAD FATAL ASSERT: XPDestroyInstance
1:54:40.620 E/SYS: THREAD FATAL ASSERT: Please report this to Laminar Research.
1:54:40.620 E/SYS: THREAD FATAL ASSERT: C:\jenkins\design-triggered\source_code\engine\plugins\glue\XPCallbacks.cpp:2658
--=={This application has crashed!}==--

[TwinFan]

Technically all done.

But we'll need to fix a shortcoming in logging, especially in picking the network time, with which all log lines start: In the current implementation there is no guarantee that the cached value is update before the first fetch in a new flight loop cycle. Rather, update is called from fixed points. That means that sometimes messages are logged with outdated network time stamps if they happen before the update is called.

We probably need to handle the cache differently: Always fetch the dataRef and update the cache value when in main thread.