On Mon, Nov 1, 2010 at 2:41 PM, Lukáš Tinkl <[email protected]> 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...
