KDE 4.11 showstopper: KMix lockup for 20 seconds, and a concept for fixing it

[Christian Esken]

Am 11.07.2013 11:12, schrieb Harald Sitter:
> Ahoy,

Hello,

thanks for your input, Harald.
>
> On Thu, Jul 11, 2013 at 12:35 AM, Christian Esken <esken at kde.org> wrote:
>> Here is some background information on what is happening:
>> MPRIS2 is using DBUS. I finally I got the notion that doing DBUS requests is
>> evil - at least ANY synchronous DBUS communication. I am pretty sure I am
>> not the first with these problems, so if anybody has working code that shows
>> how to do it I would be glad. Or review my concept code.
> This is not limited to dbus but really any syncronous interaction
> through IPC is bad. Just like synchronous interactiong between threads
> is bad, what with processes just being fancy threads from an OS point
> of view ;).

This is a bit oversimplified. For example HTTP is IPC and very 
synchronous. HTTP is usually not assigned the "bad" attribute.

> There is luckily a couple of things that can be changed without
> turning to threads and perhaps one or all of them will help improve
> the situation.
>
> First I must super highly extremly absolutely recommend generating a
> c++/qt version of the dbus interface derived from
> qdbusabstractinterface [1]. This will make the code much cleaner and
> easier to use as you do not have to constantly fiddle with QVariants
> and the likes.

>
> For example go into kde:kde-workspace/plasma/generic/dataengines/mpris2 and run
>> qdbusxml2cpp -p player org.mpris.MediaPlayer2.Player.xml
> There will now be player.cpp and player.h reflecting an interface to
> org.mpris.MediaPlayer2.Player. If you take a look at the q_slots (i.e.
> dbus functions) you'll notice that this interface is already ready for
> async usage.
Player operation is one thing. It is quite natural to do it 
asynchronously. But I do not see how coldplugging/hotplugging could
be properly handled. I mean, yes, it can be done in a very cumbersome 
way like this:

  1) Coldplug: Send "List interfaces" to get controls (async).
  2) Receive answer in a slot
Coldplug continues. Hotplug starts in the following step:
  3) From the slot do all required calls per control (async)
  4) Receive answers in a various slots.
   4a) Each slot adds the data (e.g. name or volume) it has recieved to 
the control
   4b) Each slot must control whether the data for a control is now 
complete, and the do the plug()

This is really very cumbersome. Especially step 4 is really ugly. For 
example if a single reply is missing, even if a bit optional (e.g. name 
of media player), I have a half constructed object sitting there 
forever, waiting for completion.

Effectively this means that I cannot coldplug the MPRIS2 controls at 
all. Which is also a problem for volume restoring (kmixctrl). It could 
be done, but it will again take extra code (timeouts waiting for players 
to arrive).

>
>
>
> Secondly whatever your concern/complaint with using async
> communication by means of slotting the dbuspendingcalls may be
> QDbusPendingCallWatcher [2] can probably help you handle the signals.
> Or perhaps QSignalMapper [3] is something more appropriate.
I will take a look. But I fear the coldplug/hotplug will still be messy 
(seen above).


> Thirdly after having briefly looked through the proposed QThread
> change I would highly advise against it.The implementation is
> basically reimplementating Qt (messageQueueThreadLoop -> QEventLoop;
> message -> QEvent;) this would be twice as readable code if it simply
> added 2 slots.

OK
> However short of seralizing the pluging through that messageloop thing
> (which btw is doing very efficient polling - not) the thread does
> absolutely nothing; the deadlock/timeout is still there. If you plug
> clementine, amarok and tomahawk in that order, it will take 25+
> seconds until amarok is actually plugged because clementine will still
> timeout and will until then block the thread, then if amarok also
OK, so I could possibly make other player plug faster. But I cannot fix 
any player that locks up - right? Or does my choice of 
synchronous/asynchronous calls actually affects Clementines behaviour? I 
thought the DBUS server would always do asynchronous calls, and the 
synchronous calling would just be a small convenience layer on top of 
the asynchronous call.


Thanks,
   Christian

> times out it will take 50+ seconds until tomahawk gets plugged......
>
> All in all it appears to me the thread solves nothing and might only
> cause problems in the future (as threads tend to do).
>
> [1] http://techbase.kde.org/Development/Tutorials/D-Bus/Accessing_Interfaces#Using_Classes_Generated_From_D-Bus_XML
> [2] https://qt-project.org/doc/qt-4.8/qdbuspendingcallwatcher.html
> [3] https://qt-project.org/doc/qt-4.8/qsignalmapper.html
>
> HS
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia at kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia
>