Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication
thiago at kde.org
Mon Jan 16 01:02:35 GMT 2012
On Sunday, 15 de January de 2012 18.28.28, Martin Koller wrote:
> qWarning is in QDBusDefaultConnection ctor
> > Did I place the warning in the wrong object in QtDBus?
> > Or is there something *else* creating that connection?
> no, it's the call to QDBusConnection::sessionBus()
> which creates the QDBusDefaultConnection object which throws that warning.
I know. My question is: why was QDBusConnection::sessionBus() called before
QCoreApplication was created? Can't we fix *that* by initialising it later?
> > Your description still requires the QCoreApplication object to be created
> > before the fork. It doesn't matter that you're going to close that open
> > and
> > open a new one after the fork: it's still a bad idea. Some Unix operations
> > do not survive forks, like creation of threads. If you do that, I'm
> > pretty sure QProcess will be irreparably broken.
> Sorry, I don't understand that.
> Nevertheless, I tried now what you've suggested above, namely to create my
> own QDBusConnection object to the session bus. This seems to work now,
> however as I'm new to DBus, I do not fully understand everything.
> What I've found out is that the KUniqueApplication's DBus call to
> /MainApplication only works if I create a QDBusConnection object on the
> session bus only if it uses the same name as the Qt-internal
> QDBusDefaultConnection object, which is "qt_default_session_bus", even when
> I would create my QDBusConnection objects in the way that they live as long
> as the app lives.
> Does that mean that a registered Object on DBus is linked to the
> QDBusConnection's name ?
No, it means you really did not understand the code you're trying to change.
Here's *should* go on:
1) KUniqueApplication connects to D-Bus using a private connection
2) it checks if the application is already running. If it is and we would
fork, we simply ask the running instance to show a new main window. Then we
3) if it wasn't running, it forks. The parent process waits for the child
process to register itself on the bus using the same private connection. The
child process closes its end of the private connection.
4) the child process initialises the QCoreApplication object
5) the child process opens the default, shared session bus connection and
registers itself on the bus
6) the parent process notices the child is up and running, so it exits with
_exit(0) (not exit(0)).
You're getting the warning because steps 4 and 5 are inverted. Your patch
should de-invert them by making the very first call to
QDBusConnection::sessionBus() happen after the QCoreApplication's constructor
has finished running. That means it can run in the KApplication constructor
body or in the KUniqueApplication constructor body, but not before.
> I've updated the diff https://git.reviewboard.kde.org/r/103699/diff/2/
I can't find my password. Someone convinced me a while ago to use passwords
generated with keepassx, especially because the KDE accounts kept getting
locked because of passwords being too easy to crack.
Can you send the patch?
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel