> Oh..... well, you found it: resourcewatcher.cpp uses > QDBusConnection::sessionBus()!
Aha! > Can you reproduce that crash, i.e. can you test if that fixes it? Alas, no. > Yes, I need to take the time to write a blog post on how to set up Qt for > helgrind (and helgrind for Qt). Ping me back about this in a few days if I > don't move forward on it :) Thanks very much. > Which caller, and which lock? I see no lock in the watcher -- and if you mean > the ResourceManager lock, that one is already too much of a contention point, > we should definitely not re-use it for objects that are independent from > ResourceManager. > [But of course one could say ResourceWatcher is not really independent --- I'm > lacking a big picture design about this... I should go back in time and ask > Vishesh in Berlin...] Originally I was thinking the big lock, which, most of the time, was already held by the ResourceData method that called addToWatcher, but then I thought of a way to avoid the lock being taken in the ResourceData method, so we can't do that anymore :) So I added an extra mutex for the ResourceWatcher, but I'll switch it to the single-thread stuff you suggest. >> I guess there are two possible fixes: >> 1) Just protect the ResourceWatcher with the rm mutex. >> 2) Call all methods via a QAutoConnection >> >> I like the first, because I don't really understand what is happening with >> the moveToThread stuff, but is there some reason I am missing why the mutex >> is not enough and this is really necessary? > > I'd prefer solution 2, so that the watcher lives in a single thread entirely, > which is important for libdbus usage -- and which will give better performance > than locking the big mutex even more than today. hmm, this is more tricky - we need to safely access m_watcher->resourceCount() somehow, although I think I see a way around that... > Can I let you make and test these changes? Sure. I don't want to commit some of these though, because of a plasma bug (see my email a few minutes ago) that makes the activity manager submit property changes as fast as it can, which becomes bad if submitting property changes is actually fast. Thanks, Simeon _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
