Avoid QDBusConnection Qt warning message for each KUniqueApplication

[Thiago Macieira]

On sábado, 17 de novembro de 2012 18.56.11, David Faure wrote:
> On Saturday 17 November 2012 07:22:34 Thiago Macieira wrote:
> > On sábado, 17 de novembro de 2012 10.55.01, David Faure wrote:
> > > My current broken patch is
> > > http://www.davidfaure.fr/2012/kuniqueapp_broken_fix.diff
> > > 
> > > The change from QDBusConnectionInterface* to QDBusConnection as the
> > > return
> > > value of tryToInitDBusConnection() -- which introduces a bit of noise in
> > > the  patch -- is only due to the very last hunk: so that we can make the
> > > call from parent to child using the private connection rather than
> > > sessionBus().
> > 
> > The part in kuniqueapplication.cpp is evident, but I haven't got a clue
> > what you're trying to do in kapplication.cpp. You'll need to explain.
> 
> Ah, I left a wrong if() in there. Patch updated.
> What I'm doing there is
> 1) move the registerObject before the registerService, to avoid a possible
> race; mostly unrelated to fixing the warning though. I know this works

No race is possible there. If you don't yield to the event loop, QtDBus can't 
process the message and therefore can't reply that the object path didn't 
exist.

> since I'm doing this in KDBusService (KF5) too. In fact it probably doesn't
> matter since nothing gets processed before we go to the event loop, so I
> could just revert, I guess. 

:-)

> 2) re-registerService, to replace the
> registration done by kuniqueapp on the private dbus connection. Is this
> necessary? Should I also close the private connection explicitely, or it is
> refcounted? This is what I need help with. Whatever I try, doesn't work.

You should disconnect if the process isn't about to exit. That is, if you open 
the connection in a process that survives, it needs to be disconnected. I'm 
telling you this because I could not follow the flow of the code and understand 
if the private connection is used only in processes about to exit.

I do not understand the part about re-register the service.

> This is really strange, because after this, `qdbus org.kde.kuniqueapptest`
> works (as well as `qdbus org.kde.kuniqueapptest /MainApplication
> newInstance` -- which finishes the unittest correctly.
> 
> I debugged it a bit more, and the problem is that the dbus call still ends
> up in QDBusConnectionPrivate::socketRead for the *private* dbus connection
> rather than the public one. But the registered object is in the other one.

Did you say that the private connection registers the name? That makes NO 
sense. The private connection should be just placing calls, never receiving 
them. So it does not need to register a service.

> Hence my idea of not registering before the KApp ctor, but this fails
> because the parent makes the call before the child is ready. Apparently, if
> one makes a call before the service registers, dbus errors immediately,
> while if one makes a call after the service registers but before the object
> is available, the call is queued until the server goes into the event loop.

Right.

The parent process needs to wait for the child process to signal that it's 
ready to receive the call. If I'm reading the code right, that's done by 
writing a 32-bit zero to the pipe. Since that is there, I don't understand why 
the call would fail.

> So we have to register in the child immediately after fork, but somehow I
> want to handle the call in the real QDBusConnection instance. Or maybe I
> could register the object into the private connection too? But how will
> this work for other objects being exported to dbus?

It should be registered in the regular session bus instance.

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121117/536cff6e/attachment.sig>