What happens to messages if I'm too slow processing them?

What happens if my processing of incoming messages is slower than the simulator producing new ones? If I’m not using multi-threading to ensure messages are taken in quickly and process them at my own pace, will messages be dropped?

I have a small program that starts by firing off a set of RequestSystemStates before the message handling starts, and here all answers appear to be queued, even if I reuse the RequestID. (which I obviously shouldn’t, but see my previous question, I wanted to see what happens)

When I get the next dispatch, either through a callback or directly, I get a pointer that is not mine, so how long does it stay valid? My guess is that SimConnect will want to free that memory as soon as possible. If I use CallDispatch, that would be as soon as the DispatchProc returns, but with GetNextDispatch that responsibility should be passed to me. However, with neither call there is anything said on the subject. This could imply it is not allocated and released dynamically, but using a more permanent message buffer, but then I’m even more worried; how long will that message stay valid?

The docs are definitely vague on how large the queue is or what happens when it fills up (does it drop earlier messages or just stop adding to queue). Just the call this function sufficiently frequently that the queue of information received from the server is processed note on CallDispatch(), as you’ve likely seen. Personally I’ve never ran into this nor have it seen brought up anywhere as an issue but ofc that doesn’t answer the question. One way to find out might be to just try it… :slight_smile:

As with any real-time message processing, it’s best to handle the message as quick as possible and get out of the way for the next one. Once you have a message, if the data needs processing time then it would be good to hand off to a new thread/task. Do not try to collect messages (call
CallDispatch) from separate threads.

Somewhat OT, but I’d suggest never assuming a SimConnect connection is open until you get an actual SIMCOMMENT_RECV_OPEN struct returned by the sim. If one tries to connect to it at the “wrong time” it will happily return HR OK from the SimConnect_Open() call but then fail to actually connect. Obviously this requires the message processor to already be running/available.

Cheers,
-Max