D5639: Internal cache for provider data on initialisation
Dan Leinir Turthra Jensen
noreply at phabricator.kde.org
Tue May 2 08:53:10 UTC 2017
leinir added a comment.
In https://phabricator.kde.org/D5639#105620, @apol wrote:
> Won't caching already fix the problem of traffic there? This change adds quite some complexity (all these QMutex make me cringe, these methods should always be called from the same thread anyway...)
That was my initial impression as well, but it turns out that because the requests go out at the same time, they miss each other (i am not quite sure, but i think the redirection chain might have something to do with that)... The first step does seem to not be needed, though, as with the rechecking on the xml loader which i added after the document cache, the document cache doesn't seem to ever be hit.
The mutexes are just to safeguard the QHash access, which isn't thread safe... However, i think I could likely swap that for a thread-bound global static, since while the document cache would be completely global, the xml loader one doesn't really need to be... if i take out the document cache, i can get rid of those mutexes which certainly do annoy me as well. I will rework that a bit and see what happens.
REPOSITORY
R304 KNewStuff
REVISION DETAIL
https://phabricator.kde.org/D5639
To: leinir, whiting, apol
Cc: #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170502/b7625d1c/attachment.html>
More information about the Kde-frameworks-devel
mailing list