Printable View
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).
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.
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) :Quote:
Originally Posted by wysota
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. :)Code:
If you need an example there's one bundled which demonstrates the power and flexibility of my solution.
Hope this helps. :)
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...Quote:
Originally Posted by wysota
Do you understand my choice a little better? ;)
- I don't know how D-Bus works
- D-Bus is not cross-platform
- QSettings is also used as a part of my solution
- Without network cross-platform *communication* is a mess
- How do you use shared memory safely between two applications/instances of an application?
You don't have to know how it works to use it.Quote:
Originally Posted by fullmetalcoder
Yes, but who said all platforms should use the same solution?Quote:
D-Bus is not cross-platform
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?Quote:
Without network cross-platform *communication* is a mess
Just like any application using shared memory does it... I don't know what is so unsafely in using shared memory...Quote:
How do you use shared memory safely between two applications/instances of an application?
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.Quote:
Do you understand my choice a little better? ;)
I was talking about the API...Quote:
Originally Posted by wysota
Me! :p 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 :Quote:
Originally Posted by wysota
- If the app crashes before releasing the mutex, only a reboot or a tricky low-level manip can allow the user to restart it
- what if you want you app to be configurable? i.e. the choice of single/multiple instances would be up to the user...
In having the same easy to maintain implementation for all platforms which make the classes compatible with ANY platform supported by Qt4...:)Quote:
Originally Posted by wysota
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?:confused:Quote:
Originally Posted by wysota
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...Quote:
Originally Posted by 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?
Is this platform-independent, easy to use and "dependence-free" (apart from Qt of course)???Quote:
Originally Posted by wysota
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"... :pQuote:
Originally Posted by wysota
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.Quote:
Originally Posted by fullmetalcoder
Hmm? Have you tried running two instances of any TCP server on the same port?Quote:
I'm using TCP sockets because they can't be taken over exclusively...
It's enough if it binds to 0.0.0.0 before your application binds to 127.0.0.1.Quote:
Besides it is highly unprobable that an application uses the local host to "actually do something"... :p
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... :)Quote:
Originally Posted by wysota
Sorry, no time for that now :) Any app that is longer than 20 LOC is off limits for me now :)Quote:
Originally Posted by fullmetalcoder
Then we'll stick to the TCP implementation until your LOC limits grows a bit... :pQuote:
Originally Posted by wysota
I don't say your implementation is bad. It just could be better ;)