When using QCopChannel for IPC, if qws server crashes, so do any QApplications with connected channels
So I am developing a GUI application with Qt for embedded linux 4.6.3. This system has a main GUI app, but also core and CLI apps which also use Qt framework. I would like these apps to be as independent as possible, but they need do IPC between eachother. The core is the middleman... say the GUI sets the volume, a message is passed to the core, it sends the message to appropriate driver, stores the new value in QSettings, etc... I decided to try QCopChannel to do the IPC because it extends signals/slots and doesn't require other libraries.
So the IPC works very well but I noticed that there are dependencies. First of all, the QCopChannel is under the QtGui lib so my other applications need to be QApplication, can't be QCoreApplication, even though they are non GUI. But that is fine. The main drawback is that if the GUI server application crashes, it will take down any clients that use QCopChannels connected to it. If these QCopChannels aren't set up, this won't happen.
So I'm wondering if there were a way around this behavior? It would be much better if the applications were independent. Does DBus IPC also function in the same way in this regard?
No dbus is independent. It has it's own daemon that is running in the background so even if your main application dies, it should not. As a side effect, using DBus would also allow you to test your various applications on a desktop linux.
What you could try if you want to stay with QCopChannel, is to have a "dummy" GUI application that act as a qws server (i.e. "desktop") so if another GUI application crashes, this one might survive.
Hope it helps
Yes that helps. It does sound like DBus is the way to go. I had some issues with trying to build Qt including dbus support.. I'll make another thread for that.
If that answers your question, please update the thread title prepending [solved] so other forum users may know a solution has been found :)