An asynchrous timer (in fact, all the async timers for a given process) runs on a common, separate thread. A "regular" timer is a panel control that will execute a callback on the thread that loaded the panel.
System events includes GUI events as I understand it, and these can only be processed on the thread that loaded the panel. So on the face of it, you would want to process system events using a "regular" timer, not an async timer.
I do not know exactly what would happen if you did a process system events on an async timer callback on its separate thread - some things might work, others might not.
In the old days, CVI had a "processGUIevents" function, that was different than the "process system events" function. I don't know if CVI maintains that disctinction any longer.
I don't use a timer to do a smart delay, I put the thread to sleep and the OS does the timing, rescheduling the thread after some amount of time. You don't have a problem then, unless you happen to put the "smart" delay in a separate thread (either one you have explicitly created, or the CVI runtime provided async timer thread) and expect it to update the GUI you've loaded on some other thread. I intended the "smart" delay to be used only from the main thread - that's the point of it, it allows the process to sleep but will react to user input on the GUI on short notice.
It does seem that the NI delay will spinlock, at least in some situations, and NI has told me they process system events during the delay, at least in some situations. So using the NI Delay() would have the same issues if you use it from some thread other than the thread that loaded any GUI that you are using.
If your app doesn't have a GUI, there's no problem using the smart delay on any thread I shouldn't think.
Hope this helps.
