DBus deadlock with mpris player

[George Kiagiadakis]

On Wed, Aug 1, 2012 at 5:02 AM, Simon Persson <simonpersson1 at gmail.com> wrote:
>
> Kde telepathy has a mpris based "now playing" module running in the kded
>
> daemon, during boombox startup it detected a new player and started
>
> probing it. However, BoomBox was not ready to answer.. it was still
>
> going to do creation of other objects before going to the main loop.
>
> This creation (of phonon mediaobject and kio objects) needed to talk to
>
> services in kded, but kded was waiting for boombox. deadlock.
>
> Resolve by creating mpris interface object last in startup phase.
>
>
>
>
>
> So, I was able to fix this. Other programs may be trickier to reorganize
> (during debugging I observered that amarok has the same problem).
>
>
>
> I'm not sure where to point the blame here.. applications or ktp.. but maybe
> the kded module could sleep a few seconds after detecting a new mpris player
> before it starts probing it??

No, this is not a solution to a deadlock situation. The real problem
is that both applications use QtDBus synchronously to talk to each
other. This is *wrong*. It may become a little bit trickier because
the QtDBus API is not optimized for asynchronous operations, but it
should really be used asynchronously. This way, no application would
block and wait for the other to answer and there would be no deadlock.

Therefore, this is a bug in both ktp and your application.

Regards,
George