Jump to content

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


mje

Recommended Posts

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?

Link to comment

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.

Link to comment

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.

Link to comment

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).

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.