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