Event Structure Performance and threads it can run in

[styrum]

OK, to answer my own question, looks like NI stated a long time ago it can run in any thread as long as the code you run in the case doesn't need to be executed in THE (one and only) UI thread. So, feel free to use it with user defined events for asynchronous communications between loops and separate  "modules" (actors, components, active objects, agents, daemons) if you want (a la DQMH).

From my experience though it is still better to use separate queues for anything but capturing the FP events. In fact, in my design patterns I have a separate events queue even when I do capture FP events. Because FP events are only one kind of events which I want to handle in a uniform way. Other possible types/sorts of events are apparently the actions of the module itself (say, an error happened while running some action or something else effecting the state in some other way, etc,) and, of course, the messages received from other modules. To make filtration of received messages possible, sort of preprocessing, I even maintain a queue for messages separate from the main events queue. Only whitelisted ("public") messages/events, considered as such by the receiving module are allowed to enter its main event queue. If you worry about misspelled message names or mismatches between message name and data this message queue and the corresponding loop is where you would handle those potential issues too.

Well, whatever you do, at least don't use the same event structure for handling both FP events AND more or less frequent user defined events. Just a reminder: if you want the event structure to remain responsive to both/either FP or user events, the code inside its cases should take insignificant, unnoticeable for the user time to run. If does take significant (in the context of the application) time to run it should be moved to another place, a separate loop within the same VI or even another VI running in parallel (actor/module/agent/component ...) where we can afford to wait for it finish because the overall responsiveness of the module and entire application is not affected.

https://forums.ni.com/t5/LabVIEW/event-structure-performance/td-p/400042

[styrum]

You know what? I just went and built a testbed here:

https://forums.ni.com/t5/LabVIEW/Eleven-Ways-to-Update-an-Indicator-from-within-a-subVI-Their/td-p/3...

So, everyone can see the performance differences themselves. Bad news, I am afraid for user events lovers and DQMH like frameworks that intensively use them.