Issues with Solid from trunk and qtcreator 2.0.1...

Dawit A adawit at kde.org
Wed Nov 3 04:43:01 GMT 2010


On Mon, Nov 1, 2010 at 2:41 PM, Lukáš Tinkl <ltinkl at redhat.com> wrote:
> Dne Po 1. listopadu 2010 19:24:55 Alexis Ménard napsal(a):
>> It's a supposed threading issue in dbus that has been fixed in the
>> latest version 1.4.0
>>
>> I'm running Archlinux and I got the upgrades some weeks ago. The
>> problem disappeared since then...
>
> Yup, that's why I'm not getting those issues (still running an old dbus
> version, 1.2.24)

Well, if you look at
http://bugs.freedesktop.org/show_bug.cgi?id=17754, there seems to have
been a fix in dbus >= v1.3.1 that has introduced a new lock to fix a
race condition. Now I have no clue if the fix for the race condition
is actually the cause for the freezes observed here, but it is always
curious to me that all the bug trace I do always ends up pointing to a
QDBusConnection::systemBus() call. In the back traces, I also see the
infamous dbus function, dbus_connection_send_with_reply_and_block.
Anyhow, I have CC'ed Thiago since he was involved in the bug report
mentioned above. Perhaps he will be able to shade some light on this
matter.

Having said that there are several low hanging fruit optimizations
that can be done in UDisksDevice. For example, the over aggressive
caching in UDisksDevice::checkCache, where if the properties cache is
empty it attempts to retrieve all the properties for a device, has a
very deterimental effect if create temporary UDisksDevice objects. For
example, look at UDisksManager::allDevices(). In such scenarios, I the
aggressiveness actually works against you. Just put a debug statement
in the for loop statement of  UDisksDevice::allProperties() and
attempt to open KDE's file dialog from any application to see what I
mean...




More information about the kde-core-devel mailing list