On Fri, Mar 8, 2013 at 5:21 PM, David Faure <[email protected]> wrote: > Debugging slowness in kmail showed me an issue there: > > 209│ bool Nepomuk2::Resource::hasProperty( const QUrl& uri ) const > 210│ { > 211├> determineFinalResourceData(); > 212│ return m_data->hasProperty( uri ); > 213│ } > > Even though we prepare the resource in a different thread (in > asyncnepomukretriever) so all props are available, we're waiting on the > ResourceManager mutex in that method, to read the properties. > > Ah, but determineUri() does nothing if m_uri is set (not empty), anyway. > So how about the attached patch? >
Ship it! > > Note that I detected an error in the use of the "modification mutex" within > Resource. I had used it only for "writes" to variables, but obviously the > reads must be mutex-protected too. Now that I understand the C++11 memory > model, it's a lot clearer :) > I'll rename the mutex then, it's not a "modification mutex", it's a mutex > for > the resource member variables. > Uhm. Okay. > > Anyhow, please validate the URI thing -- am I right that it's empty > initially, > and then it's set (in determineUri()), and then never changed again? > Yes. It's not always empty initially, sometimes it is provided in the constructor. But it is never changed again. > -- > David Faure, [email protected], http://www.davidfaure.fr > Working on KDE, in particular KDE Frameworks 5 > > _______________________________________________ > Nepomuk mailing list > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk > > -- Vishesh Handa
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
