You _may_ call any XPLM call from inside any XPLM callback, because the callbacks are always delivered on the main thread. The rule of the XPLM is “call us only on the thread on which we call you”, and in practice that thread has always been the main thread. We are probably never going to change that because UI callbacks naturally come from the main thread, so if we have to pick one, that’s the sane one to pick.

So from a flight loop callback, you can call XPLM routines to read/write datarefs, create windows, etc.

Way back in the day, there were _further_ restrictions, e.g. if you registered a flight loop from inside another flight loop callback, the XPLM would intermittently blow up; we had a Lot of fine print guidelines. All of that was fixed in the XPLM 2 for X-Plane 9; for v9, 10 and 11, you can call any other XPLM call from any XPLM call. (I think this even includes deleting an object from within its own callback.)

does this mean we may or may not make xplm calls inside a flight loop callback now?

Right – but this is a data point specific to sim-connect. There’s nothin fundamental about the sim-connect design that would make it fundamentally more expensive than synchronous plugins.

The achieved frame rate is crucial. If I deactivate SimConnect in my plugin, it will increase by one frame. With a total loss of 1.5 frames by my plugin that’s a big part. By contrast, the proportion of the map window drawn at 15 Hz is negligible.

What makes you say that an asynchronous interface would cause “a lot of extra” load on the processor?

The flight loop does not _wait_ for plugins (where by “wait” I mean sleep the thread by blocking on an OS sync mechanism like a semaphore). Plugins are executed _synchronously_ on the main thread non-concurrently to the FM, so your plugin callback’s execution time is part of the “critical path” of the main thread through the sim loop.

There are concurrent worker threads in X-Plane and they are able to do a variety of background work, some of which is picked up within the frame and some of which is picked up after several frames. Plugins do not have access to this mechanism, except when calling XPLMLoadObjectAsync – in that case, the work of loading and building the OBJ file is done on this background pool and picked up later.

Doesn’t the flight loop wait for each plugin to finish? Serially? When I inject a sleep(1) into a plugin, FPS = 1 as well. Ergo, if the master plugin thread forces a join after spawning a batch in which each worker is known to invoke a different API call, where is the harm?

I suppose another way of asking is: is the worker that loops through the plugins not the only concurrently running thread in the xplane universe even though what my eyes see on the screen doesn’t update?