LabVIEW Built Windows Applications - Preventing the "Not Responding" Label

[mje]

I have a Windows specific application I wrote in LabVIEW, and sometimes when I need to churn through a lot of data or become disk-bound for a while, Windows will label my application as "Not Responding". What's a good way to prevent this from happening?

I know back in the days when I programmed using MFC it was really just a matter of making sure the main Windows messaging loop got serviced from time to time. In LabVIEW do we really have any option other than perhaps sprinkling doses of waits in our code and hoping the kernel gets called in the interim? Even in a more general sense, what's a good way to keep a host OS happy when embarking on epic journeys of computation or serialization?

[asbo]

Loops with 0ms waits (which allows CPU-yielding) really is the best tool we have. This is sometimes annoying to incorporate with significant disk IO and isn't a cure-all - for example, with ActiveX/dotNET/CLNs, anything you have to call in the UI thread is immune to this.

[mje]

Indeed, the very reason I posted this was because I had a loop that the 0 ms wait didn't do the trick. The loop does wrap a CLN, but is not set to use the UI thread exclusively. Forcing a non-zero wait seems to solve the problem for me and given the maximum number of iterations I'll be bounded to isn't prohibitive, but I can imagine cases where I'd rather not have to introduce forced minimum delays.

[ShaunR]

Another thing you can do is set the subsystems execution system to something like "Other1" then dynamically launch it. This will force it into a different thread pool and the LV scheduler should do the rest. It will also give you better control over how much slice time it can consume by setting the different priorities (this assumes your DLL supports multi-threading and doesn't require the dreaded orange node).

[GregR]

You will only get that label when the UI thread is not able to handle OS messages. This can happen through direct routes like a long CLN run in the UI thread. That is definitely the first thing to check.

It can also happen through indirect routes. If you are doing something that is very disk or memory intensive, it can cause delays that slow down what would normally be very fast operations in the UI thread. If you are paging in a huge buffer in another thread and the UI happens to need some piece of memory paged in, then the UI in theory could be blocked long enough to cause the OS to consider the process hung. With the speed of most modern machines, this is unlikely but it is possible.

[jaegen]

Even in a more general sense, what's a good way to keep a host OS happy when embarking on epic journeys of computation or serialization?

You need to feed it a snack every now and then - it gets hungry on long journeys...