08-16-2023 02:40 AM - edited 08-16-2023 10:11 AM
My source code is fully Windows/Linux compatible, I compile it for Windows and Linux (LabVIEW 2020 Sp1)
On Windows, the INI file next to the EXE contains the tokken 'AllowMultipleInstances=False' and it prevents multiple instances to run but on Linux Ubuntu I can can't get this to work... My conf file is this :
But each time I click on the shortcut a new instance of the app is launched, what am I missing?
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
08-16-2023 09:02 AM
@TiTou wrote:
... but on Linux Ubuntu I can get this to work.
Did you mean to say "... but on Linux Ubuntu I can't get this to work."?
08-16-2023 10:12 AM
you're right, i've just edited my original post.
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
11-08-2023 05:15 AM - edited 11-08-2023 05:17 AM
I'm not sure there is even a built in mechanism to prevent multiple instances on other systems than Windows.
The way this is implemented in Windows is actually through DDE (yes right, DDE a technology from Windows 3.0 days, which Microsoft would rather want anyone to forget about). It attempts to talk to the LabVIEW DDE server (that every application needed to have in order to allow opening files from the File Manager) and if that fails it continues and starts up LabVIEW. Otherwise it passes whatever command line parameters it received to the DDE server and then terminates itself.
Since there is no DDE on non-Windows systems, it could only work if NI implemented some other internal server interface (besides the VI Server interface and Web Server interface, and Debug Server interface and what else) and I'm pretty sure it doesn't.
That all said it is typical on Linux to solve such things through a shell script used to launch the actual application. Check for the process in question to exist and if it does, refuse to launch another process by simply terminating.
11-08-2023 06:46 AM
yes, currently I use when the app starts
pgrep <app-filename>
and indeed, it this returns a PID, close.
it's not perfect because if the app-file is duplicated with a different name it will not work, but it's good enough for me for the time being.
When deploying to customers, the app runs as a service.
From LabVIEW we build an so file an use a c-built app to call the so file, and being a service ensures that there is only one instance running.
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
11-08-2023 07:26 AM - edited 11-08-2023 07:27 AM
@TiTou wrote:
it's not perfect because if the app-file is duplicated with a different name it will not work, but it's good enough for me for the time being.
I believe that the Windows version also uses the process executable name for a built application, to define its DDE server name. So it's probably not really better than what you have now!