How to allow just one instance from c++ application exe?

[Magdy]

How to allow just one instance to be running from c++ application
exe?!

More details:
Platform: windows, but I prefer a cross-platform solution...

If the user ran the exe and there is another instance already running,
the new exe sends message (ex. string) to the running one and
terminate.

Any ideas and/or thoughts will be much appreciated.

 

[Victor Bazarov]

How to allow just one instance to be running from c++ application
exe?!

That's platform-specific. Ask in the newsgroup that deals with your
plaform.

More details:
Platform: windows, but I prefer a cross-platform solution...

Try 'comp.os.ms-windows.programmer' (or the appropriate NG from
'microsoft.public.*' hierarchy).

If the user ran the exe and there is another instance already running,
the new exe sends message (ex. string) to the running one and
terminate.

Any ideas and/or thoughts will be much appreciated.

Not a language feature. Off-topic.

V

 

[James Kanze]

How to allow just one instance to be running from c++ application
exe?!

More details:
Platform: windows, but I prefer a cross-platform solution...

If the user ran the exe and there is another instance already running,
the new exe sends message (ex. string) to the running one and
terminate.

Any ideas and/or thoughts will be much appreciated.

There's no standard solution; the usual solution under Unix
(which should also work under Windows) is to atomically create a
file with the process id of the program in a fixed location.
The "atomically" means that you'll have to use some platform
specific requests, not simple ofstream. Under Unix, this is
done by using the modes O_EXCL | O_CREAT in the open request,
under Windows, there is a flag CREATE_NEW for CreateFile which
sounds like it would do the same thing. If the open succeeds,
you're fine. If it fails, and the error is EEXIST (Unix) or
ERROR_FILE_EXISTS (Windows), then either another instance of the
executable is running, or a previous instance didn't terminate
cleanly, and failed to delete the file. (To solve the problem
concerning failing to delete the file: use a small batch script
to start your program, which deletes the file when your program
has finished, regardless of why it finished, and add an
automatic action on booting to delete the file.) Any other
error, of course, is a serious problem, and probably means that
your program wasn't installed correctly.

It's probably possible to use the registry, rather than a file,
under Windows; I'm not familiar with this, however. And under
Unix (and possibly Windows as well), it's possible to obtain a
list of running processes (reading from a pipe from ps under
Unix), and see if your program is there---this solution is
subject to race conditions, however.

 

[Magdy Wageeh]

As you noted, this usual solution does not work well if the program does
not delete the file for some reason.

A robust solution is to create the file with no O_EXCL flag. And then
try locking it. If locking fails, then another instance of the
application is holding it. If the application that holds the lock
terminates for any reason, the operating system releases the lock anyway.

Very well, I prefer the lock solution, but I think this means that I
have to deal with multithreading and mutex or whatever locking
mechanism under c++.

I am not familiar at all with multithreading in c++. can you (or
anyone here) suggest/guide me how to accomplish the locking solution
mentioned?

Thanks!

 

[Thomas J. Gritzan]

How to allow just one instance to be running from c++ application
exe?!

There's no standard solution; the usual solution under Unix
(which should also work under Windows) is to atomically create a
file with the process id of the program in a fixed location. [...]
It's probably possible to use the registry, rather than a file,
under Windows;

The usual solutions under Windows are to create a named mutex with a
unique name per application (i.e. appliaction name or GUID) or a locked
file in the users profile directory.

The MSDN for CreateMutex says:
http://msdn.microsoft.com/en-us/library/ms682411(VS.85).aspx

"If you are using a named mutex to limit your application to a single
instance, a malicious user can create this mutex before you do and
prevent your application from starting. To prevent this situation,
create a randomly named mutex and store the name so that it can only be
obtained by an authorized user. Alternatively, you can use a file for
this purpose. To limit your application to one instance per user, create
a locked file in the user's profile directory."

 

[James Kanze]

As you noted, this usual solution does not work well if the
program does not delete the file for some reason.

A robust solution is to create the file with no O_EXCL flag.
And then try locking it. If locking fails, then another
instance of the application is holding it. If the application
that holds the lock terminates for any reason, the operating
system releases the lock anyway.

Yes, that sounds like it would be a better solution. I probably
should have qualified my suggestings as the "historically usual
solution"---it was certainly the usual solution before Unix
supported file locking, and probably for a long time afterwards,
but I don't know too much about today.

 

[Maxim Yegorushkin]

Yes, that sounds like it would be a better solution. I probably
should have qualified my suggestings as the "historically usual
solution"---it was certainly the usual solution before Unix
supported file locking, and probably for a long time afterwards,
but I don't know too much about today.

Too bad that today Firefox and eMule for Linux still use the old method.
Occasionally, these applications won't start because their stale pid
file have not been removed, so I have to remove these files manually. If
these applications used file locking, I would not have to know about the
existence of those files.