[Discussion]Process Execution System

[cbler]

A general question about setting up the preferred execution system of a process in the JKI-SMO architecture. I appreciate any help and insight that can be provided.

I have a JKI-SMO with a process which is getting blocked when a screen in another JKI-SMO opens the windows file dialog box. I believe I understand why it is getting blocked (both the screen and process are ending up in the user interface [UI] preferred execution system [PES], oh, or the process is doing something [like creating a queue] which can only runs in the UI PES).

Is getting the process to run in another PES, as simple as changing the PES of the process VI in the VI Properties dialog box? Because I have tried that and it doesn't seem to help. But I am going to review the process and see what resources it creates, in case that is the cause of the issue.

Are there any tools to help debug the PES (ie, what VI is in what PES)? I tried the Desktop Execution Trace Toolkit, but didn't have any luck. It does give thread ID but mapping that to PES......???

[jimkring]

From what I recall, the blocking has to do with certain function calls that use and block "the root loop". In my experience, I observe that functions like Open VI Reference will be blocked while Windows File Dialog is open, One-button Dialog is open, Menubar is active, etc. I'm not sure this has to do with the execution system that a VI is running in. Here's some good reading: http://www.labviewcraftsmen.com/blog/the-root-loop

Hope that helps and I didn't miss the main point or go off in the wrong direction

[cbler]

I loved that blog post, thanks for the link; this is definitely a panda ant scenario.

In my application, I have created a complicated hierarchy (seemed like a good idea at the time ;-) of classes (SMO) with processes that provide the communication to external applications. It goes something like TCP Client >> General Client API >> Specific Client API. Communication with Specific Client 1 and Specific Client 2 works brilliantly, until the user performs an action in a completely unrelated class in my application, that result in the opening of the file dialog. This causes that part of my application to enter the root loop, block the single thread in the UI preferred execution system [PES] and also block any other activities that need the root loop, if I have use all the vocabulary correctly. Then both external applications generate communication errors because my application has stopped replying to messages.

My initial assumption (and what motivated this discussion), was that my SMO process was running in the UI thread and I was wondering how others avoided or managed this issue of PES and SMO processes. LabVIEW's easy debugging has spoiled me and so I find debugging this issue very tedious and time consuming. I'm off to debug some more, I hope I don't get stung.... Thanks for your time - Chris