Multiple program instances

[scwizard]

For a lot of programs, such as Gaim, when you run the binary if there is already a instance of the program open currently opened program will execute some kind of command and a new task will not be started.

Does Qt support a cross platform way to do this or do I need to use some kind of platform specific function to read the process list (or something to that extent).

[wysota]

There exists a QtSolution which does what you want in a portable way. If you have a commercial licence with QtSolution subscription, you can make use of it. If not, you'll have to implement it yourself in a platform dependent way.

[fullmetalcoder]

If not, you'll have to implement it yourself in a platform dependent way.

Alternatively you can use the GPL'ed solution I've myself developped for Edyuk which provide similar functionnality in a platform independent way through local networking (i.e. TCP sockets/server on 127.0.0.1). It is available in the Edyuk source packages from version 0.8.0-rc1 or in the SVN (recommeded) :

$ svn co https://edyuk.svn.sourceforge.net/svnroot/edyuk/3rdparty/qcumber qcumber

$ svn co https://edyuk.svn.sourceforge.net/svnroot/edyuk/3rdparty/qcumber qcumber

To copy to clipboard, switch view to plain text mode 

Note : QCumber is the name of a multi-purpose library meant to bring features frequently used by many apps (instance control and communication, shortcut management, safe shared settings, ...). It is still under active development but wht's available works pretty well.

If you need an example there's one bundled which demonstrates the power and flexibility of my solution.

Hope this helps.

[wysota]

To be honest now I'd expect a singleton app to be handled on Unix through dbus and not a network socket Using QSettings or shared memory is also a way...

[fullmetalcoder]

To be honest now I'd expect a singleton app to be handled on Unix through dbus and not a network socket Using QSettings or shared memory is also a way...

Well...

1. I don't know how D-Bus works
2. D-Bus is not cross-platform
3. QSettings is also used as a part of my solution
4. Without network cross-platform *communication* is a mess
5. How do you use shared memory safely between two applications/instances of an application?

Do you understand my choice a little better?

[wysota]

I don't know how D-Bus works

You don't have to know how it works to use it.

D-Bus is not cross-platform

Yes, but who said all platforms should use the same solution?

Without network cross-platform *communication* is a mess

I don't know if I understand... Where is the "cross-platforminess" in talking between two instances of a program running on the same computer?

How do you use shared memory safely between two applications/instances of an application?

Just like any application using shared memory does it... I don't know what is so unsafely in using shared memory...

Do you understand my choice a little better?

Honestly? No. The main problem I see is that you can have clashes between two completely different applications that by accident use the same port for their "singleton" sockets. I must admit I didn't read your code, that's why I'm having these doubts.

[fullmetalcoder]

You don't have to know how it works to use it.

I was talking about the API...

Yes, but who said all platforms should use the same solution?

Me! Because it's easier to write and maintain.... Besides it allows real platform independence without bringing extra dependencies. Another interest is that deadlocks are very unlikely to occur and easy to overcome. For instance if your want to use system mutex (under windows or linux) to handle instance limiting you will face two problems :

1. If the app crashes before releasing the mutex, only a reboot or a tricky low-level manip can allow the user to restart it
2. what if you want you app to be configurable? i.e. the choice of single/multiple instances would be up to the user...

I don't know if I understand... Where is the "cross-platforminess" in talking between two instances of a program running on the same computer?

In having the same easy to maintain implementation for all platforms which make the classes compatible with ANY platform supported by Qt4...

Just like any application using shared memory does it... I don't know what is so unsafely in using shared memory...

I've never used shared memory so I probably can't tell you... As you seem to known it maybe you can tell how easy to use shared memory is... Anyway I don't really see the point of shared memory here... Would you like to use it as a message bus? If so how? And how do you effectively share this memory exclusively with other instances of your app?

Honestly? No. The main problem I see is that you can have clashes between two completely different applications that by accident use the same port for their "singleton" sockets. I must admit I didn't read your code, that's why I'm having these doubts.

This is very unlikely to happen but can anyway be easily fixed, if faced, by prepending a pre-application ID string to the messages sent...

[wysota]

I'll just answer that part about shared memory. It's called shared because different processes can have it in their memory space simoultaneously. Checking if an application instance exists is just about checking if a particular shared memory segment exists and maybe also what it contains.

Another possiblity is to use named pipes or message queues.

BTW. Are you using TCP or UDP sockets and why? How do you bind to an address? What happens if another application (I mean one that actually uses the socket for something) binds the socket exclusively?

[fullmetalcoder]

Another possiblity is to use named pipes or message queues.

Is this platform-independent, easy to use and "dependence-free" (apart from Qt of course)???

BTW. Are you using TCP or UDP sockets and why? How do you bind to an address? What happens if another application (I mean one that actually uses the socket for something) binds the socket exclusively?

I'm using TCP sockets because they can't be taken over exclusively... Besides it is highly unprobable that an application uses the local host to "actually do something"...

[wysota]

Is this platform-independent, easy to use and "dependence-free" (apart from Qt of course)???

Dependence-free - yes, easy to use - yes, platform independent - depends what you mean Named pipes exist on most (all?) modern systems, but the API probably differs.

I'm using TCP sockets because they can't be taken over exclusively...

Hmm? Have you tried running two instances of any TCP server on the same port?

Besides it is highly unprobable that an application uses the local host to "actually do something"...

It's enough if it binds to 0.0.0.0 before your application binds to 127.0.0.1.

What about using UDP? It's lightweight, reliable when used on loopback device and datagram oriented, so it should be easier to handle. It's also connectionless, so many apps can use it and it's less probable to cause conflicts with other applications.

[fullmetalcoder]

What about using UDP? It's lightweight, reliable when used on loopback device and datagram oriented, so it should be easier to handle. It's also connectionless, so many apps can use it and it's less probable to cause conflicts with other applications.

I've tried using UDP but I did not come to any decent result. Besides, what I've read in the docs makes me think that it's the exact contrary of what I want in term of listenning mechanism... Actually I'm not quite sure I fully understood the restrictions (differences) UDP brings but my tests appeared to be in favour of TCP... Maybe you can show me how wrong I was just by providing a UDP based implementation of the QInterProcessChannel class...

[wysota]

Maybe you can show me how wrong I was just by providing a UDP based implementation of the QInterProcessChannel class...

Sorry, no time for that now Any app that is longer than 20 LOC is off limits for me now

[fullmetalcoder]

Sorry, no time for that now Any app that is longer than 20 LOC is off limits for me now

Then we'll stick to the TCP implementation until your LOC limits grows a bit...

[wysota]

I don't say your implementation is bad. It just could be better