LabVIEW
Force Call Library Function (DLL) to run outside of UI thread (Run in any thread not suitable)
Solved!
I'm using the Windows API to create a process using the CreateProcess function and redirecting its stdin, out and error handles to separate pipes.
Creating a Child Process with Redirected Input and Output
Hopefully this will be an improved/more interactive version of LabVIEW's System Exec VI to interact with PLink.
All of the redirection is working well using WriteFile and ReadFile, but the initial process creation can hang.
The process I am launching could take >10 seconds before it fails and times out. This causes the LabVIEW UI to become unresponsive and trigger the faded screen and loading cursor in Windows.
I have set the Call Library Function node to "Run in any thread" under the Thread options, but it still hangs. Is there any way to force this function call to be executed on a non UI thread?
I've also tried calling it asynchronously and specifying another thread in the VI's Execution parameters (standard, other 2 etc.).
I would like to keep all of the calling code native to LabVIEW, no external self created DLLs.
@matt.baker wrote:
I'm using the Windows API to create a process using the CreateProcess function and redirecting its stdin, out and error handles to separate pipes.
Creating a Child Process with Redirected Input and Output
Hopefully this will be an improved/more interactive version of LabVIEW's System Exec VI to interact with PLink.
All of the redirection is working well using WriteFile and ReadFile, but the initial process creation can hang.
The process I am launching could take >10 seconds before it fails and times out. This causes the LabVIEW UI to become unresponsive and trigger the faded screen and loading cursor in Windows.
I have set the Call Library Function node to "Run in any thread" under the Thread options, but it still hangs. Is there any way to force this function call to be executed on a non UI thread?
I've also tried calling it asynchronously and specifying another thread in the VI's Execution parameters (standard, other 2 etc.).
I would like to keep all of the calling code native to LabVIEW, no external self created DLLs.
If you set the Cal Library Node to "run in any thread" it will be executed in whatever thread the actual VI happens to execute at that moment. Unless you set the VI or one of its callers to execute explicitly in the UI thread, there is absolutely no chance that the Call Library Node will be executed in the UI thread.
Thanks for the info.
Hmm, I wonder what's causing it to freeze. NI are doing something clever in their SystemExec vi, as setting it to non completion waiting doesn't result in a lock up.
I'll have another look.
There is nothing clever about that. If you tell the System Exec not to wait for the program that is called to finish, it will not wait for that program to finish.
Basically SystemExec does more or less directly call the Windows CreateProcess() API and one of the parameters of that API is to wait for the called process to terminate. And CreateProcess() then simply will wait until the program that was launched actually terminates. This can be interesting if you want to read the standard output of the command line tool. Obviously when you don't wait for the program to terminate there is no way to reliably retrieve any standard output from the program by SystemExec.
Maybe if you show your code we could tell you better what is causing this problem.
You are right. I was too focused on the process creation causing the problem, rather than something else.
I've since rechecked my test program and it's all working as expected now; no hangs at all.
I have a feeling the problem may have been with reading the processes' stdout without checking if there was actually any data in the buffer, but I've have no backup of the library in that state.
Thanks for your help
