remote execution new thread

[pwaszkewitz]

Hello,

I am having a problem here with a mix of threads and remote execution.

As I see it, a sequence call on a remote computer is synchronous, i.e., it returns when the execution of the sequence on the remote computer is finished.

Now I need sequence on the remote computer to run "indefinitely", i.e., until something specific happens. I see two ways to achieve this. Let's say I have a "host sequence" which is my main application on the main computer, a "test sequence" which does the actual work and is the one that keeps on running; finally I have a "control sequence" which starts the test sequence.

• The first scenario: "host sequence" starts "control sequence" locally in a new thread which in turn calls "test sequence" remotely.; now "control sequence" is blocked, but "host sequence" should run on. As I exptected, the call to the "control sequence" returned immediately (of course with the "Automatically Wait for the Thread..." option not checked) and "host sequence" did continue.
• The second scenario: "host sequence" starts "control sequence" remotely; of course "host" sequence is now blocked until "control sequence" returns. "Control sequence" starts "test sequence" localls (from its own point of view, so this is still "remote") in a new thread without waiting for the thread to end.

I assumed that in the second case, "control sequence" would return immediately after creating the thread for "test sequence" and thus would the remote sequence call so that "host sequence" continues.

Now comes the part I do not understand: When I test the call from "control sequence" to "test sequence" in the second scenario, it does return immediately. But when I call "control sequence" remotely from my "host sequence", the remote call does not return.

Any ideas what is causing this behavior and whether it is at all possible to open new threads in a remote execution (which would be quite important for my upcoming applications ...)

Thanks

Peter

[pwaszkewitz]

Yes, I am answering my own post ... actually, I found some interesting behavior of remote exections and perhaps someone can explain this to me.

Currently, I am testing all this locally on my machine. I specify the remote server in three different ways: as the actual name of my computer, as "localhost" and as "127.0.0.1", and I notice different behavior of remote executions.

To remember, the scenario I want to create is that my Host sequence calls a remote sequence which in turn calls a sequence locally (that is, on the remote computer) in a new thread:

HostSequence (remote call) -> ControlSequence (local call in new thread without waiting for end of thread) -> TestSequence

For a test, I placed message popups with timeout button in the remote sequence. These popups do not appear when the remote computer is specified as 127.0.0.1, but in the two other cases they do.

Using these popups, I can verify that the TestSequence is actually started by the ControlSequence, however the call to ControlSequence does not return.

I modified my scenario as follows:

HostSequence (remote call) -> ControlSequence (local call in new execution without waiting for end) -> TestSequence

Again, the TestSequence is started, but the remote call to the ControlSequence does not return.

So now I have two questions:

• Why do the popups not appear, when using 127.0.0.1 as remote computer specification?
• Is it at all possible to do sequence calls in a new thread inside a sequence which is executed on a remote computer?

Best regards,

Peter Waszkewitz

[nayer]

Hello Peter,

You can try unchecking the  Automatically wait for the thread to complete at the end of the current sequence on the sequence call which is executing remotely. I also another question on why are you trying to specify the remote computer as your host machine.

Thanks 

NI-khil

[pwaszkewitz]

Hello NI-khil,

there are two reasons why I use my machine as the host and the remote at the same time. First one is to test the remote sequence execution without needing a second machine. Second, and more important: we do that in actual applications to keep memory-intensive and potentially error-prone operations (e.g., in algorithm libraries) outside the controlling TestStand process. When the test steps are VIs, you have that automatically, since they run in the LabView runtime process, but we are mainly using DLLs and .NET assemblies in our test steps. It is much safer, in my experience, to kill a process in an emergency than to kill a thread within a process.

Now to the waiting for the thread. I tried that without the result I expected; but I think that now I have understood what happens: the remote sequence which starts the thread actually does end immediately, but a remote sequence always starts a new execution in the remote engine process and the call does not return until the execution is finished. And when I thought about it a little longer, I understood that it must be so: otherwise you would have an execution running without a controlling sequence call instance.

So, it is possible to start new threads and executions in a remotely called sequence without restriction, but if one wants the host sequence to continue after starting the remote execution, it needs a local thread for each remote execution it starts.

Thanks.

Peter