Linux Always Opens New App Instance

[JamesMc86]

This is probably a nice thing! However we should check that our detection VI for this still works and probably expose this as a public API so that tool builders can account for this.

For example, I would want to auto-exit LabVIEW if I knew I was the only thing running in the app instance.

[JamesMc86]

@jimkring @joerghampel curious if you or your teams have any feelings on changes because of this?

We can still push a first version that just works like this. I'm tempted to add a "quit if single instance" option, or perhaps on Linux we just need to use the kill command at all times.

[joerghampel]

We usually leave LV open until the end of the pipeline. Meaning the first step (initialising stuff in our case) opens LabVIEW, all the consecutive stages reuse the already-opened app instance, and the last step (teardown in our case) quits LabVIEW.

It seems like we'll have to treat RAT and G-CLI differently on Linux anyhow, so I don't have a strong feeling about whether G-CLI is supporting this.

[AlexanderElbert]

Unlike on Windows, currently on my test RHEL, every g-cli call starts a new LabVIEW instance. I'm not sure, if this might be a reason for problems in the communication.

I would be happy if the default behaviour on both systems would be the same (use single instance). Adding an option to create a new instance for each call might be useful.

[AlexanderElbert]

Update:

Adding the --kill option, does not close the LabVIEW instance! (so doesn't --kill-timeout)

I feel there are communication issues going on. I just started testing and this might not be related to new LV instances, but I'm seeing these messages:

[DEBUG] Process launched with PID 57926
[INFO] Process Lost
[DEBUG] The LabVIEW process appears to have closed down
Error: No connection established with application.
Caused by:
    Timed out waiting for app to connect to g-cli
Location:
    src/main.rs:62:10

And this Error

[ERROR] Comms Error: Unexpected EOF Error: LabVIEW has probably closed the connection

And I can see this message each time g-cli is being called in the same pipeline:

05:43:32.646 [DEBUG] Process launched with PID 4574
05:43:32.727 [INFO] Process Lost
05:43:32.727 [DEBUG] The LabVIEW process appears to have closed down
...
05:43:35.738 [DEBUG] Process launched with PID 4645
05:43:35.850 [INFO] Process Lost
05:43:35.850 [DEBUG] The LabVIEW process appears to have closed down
...
05:45:14.905 [DEBUG] Process launched with PID 4823
05:45:14.982 [INFO] Process Lost
05:45:14.982 [DEBUG] The LabVIEW process appears to have closed down

I could only run my pipeline with 13 calls to g-cli successfully, when I was manually closing the LV instances...

[jimkring]

I have the same behavior on Ubuntu. - the —kill arg doesn’t have any effect - a new instance of LV opens for each gcli command. (I actually kind of like this behavior, because it enables me to easily start up multiple instances of work in parallel) -- Jim Sent from my mobile.

[JamesMc86]

Unlike on Windows, currently on my test RHEL, every g-cli call starts a new LabVIEW instance. I'm not sure, if this might be a reason for problems in the communication.

I would be happy if the default behaviour on both systems would be the same (use single instance). Adding an option to create a new instance for each call might be useful.

Unfortunately I don't know that we can. On Windows it uses a Windows-only mechanism to launch in the existing application. Based on what I'm seeing I think this may just not exist on Linux but we will have to dig deeper

That is particularly unfortunate about the kill command and that will need further investigation.

[jimkring]

I think that the Ubuntu/Gnome desktop has a mechanism to open files in an already running instance of an app. I think I've seen this work with LabVIEW once or twice, but I don't know how (or how well) it works under the hood.

Regarding the --kill command, I'm surprised this doesn't work. Is it a security-related issue? Is the g-cli process not allowed to send a kill signal into LabVIEW?

One idea (that might be nice in addition to the --kill option) would be to add a new --exit flag (to "Exit LabVIEW on Completion") that is received by the Start CLI Interface.vi, passed along the session wire, and then handled in the Exit with Error Code.vi by invoking LabVIEW's "Exit" function:

I've been doing this as a user-defined, additional argument, and it would be great it it were built in.

[JamesMc86]

Digging deeper into this and getting a little confused!

In short though files from the file browser open in the same instance so while this seems to be the default behaviour for cli launches there is a signalling mechanism.

That said, I'm inclined to close this as I doubt there will be an easy workaround to the multi-instances on the CLI.

The other issues here are being tracked as separate issues (#157) and #156 which depends on #163

[JamesMc86]

I'm going to backtrack here a bit because this is simpler than I thought. By looking at the desktop integration I can see the -launch parameter will actually launch into an existing instance.

So we could make this consistent with the existing behaviour but have an option to launch in a new instance. Or make the new instance default? Its kind of cool and wish Windows had it as an option!

However there does seem to be problems:

1. It favours an already open alternative version.
2. It doesn't appear to detach the child process like in Windows so when you kill g-cli the labview process dies as well.

[joerghampel]

I would prefer consistency plus a new option.