anthonyfieroni added inline comments.
INLINE COMMENTS
> dfaure wrote in kiconloader.cpp:616
> This locks and unlocks three times in a row, which is not only slightly
> inefficient, it also means that another thread could interleave calls in
> between, and get completely inconsistent state.
Yeah, i saw it, i'll made a sequenceLock like this
void sequenceLock(std::function<void()> func)
{
QMutexLocker locker(&mutex);
func():
}
//usage
S_D(d)->sequenceLocker([d, _appname, extraSearchPaths]() {
d->mIconCache->clear();
d->clear();
d->init(_appname, extraSearchPaths);
});
Are you ok with such approach?
> dfaure wrote in kiconloader.cpp:1829
> similar here, if another thread changes mIconAvailability between the
> previous line and this one, you'll end up comparing iterators for a different
> container, that will never work
Here with sure with other approach.
REPOSITORY
R302 KIconThemes
REVISION DETAIL
https://phabricator.kde.org/D13627
To: anthonyfieroni, davidedmundson, dfaure, #frameworks
Cc: kde-frameworks-devel, michaelh, ngraham, bruns
