There is another paradigm which usually works better. In any given loop, your best way to stop the loop is to use its native control mechanism. In your example, you have a data acquisition loop and a UI loop. Data acquisition loops are typically controlled by some sort of state machine or command processor, often queue based. UI loops are controlled by an event structure. The acquisition loop should exit when it gets a command or state transition to exit. In this case, it should fire a user event which will cause the UI loop to exit. The UI loop can exit due to a variety of control, menu, or user events. In this case, it should send a command to the DAQ loop to exit.
But wait, you say, my DAQ loop does not have a command processor, so using the functional global is far easier. If true, you need to refactor your DAQ loop so it is a command processor, state machine, or something similar. Using any global, including functional globals, for control purposes usually points to a place you could have a better design. Virtually all LabVIEW users go through the Global/Local » Functional Global » Queue/Notifier/Event command passing phases. I certainly did, and I don't want to go back. I consider functional global command and control variables a hack to use when you are in a hurry, but something to be solved with proper messaging in the future. Simply put, globals break data flow and should be used only when absolutely needed. The more you learn data flow, the more you avoid globals - by choice. You simply do not need them in virtually all cases.
