D22333: Move Solid::Device::listFromQuery calls to a separate thread

Aleix Pol Gonzalez noreply at phabricator.kde.org
Thu Jul 11 19:47:29 BST 2019


apol added a comment.


  In D22333#494253 <https://phabricator.kde.org/D22333#494253>, @bruns wrote:
  
  > In D22333#494152 <https://phabricator.kde.org/D22333#494152>, @apol wrote:
  >
  > > In D22333#494146 <https://phabricator.kde.org/D22333#494146>, @bruns wrote:
  > >
  > > > Why not just a singleshot timer from the constructor? Avoids any initial blocking ...
  > >
  > >
  > > Initial, but doesn't fix the problem. We could potentially delay this few seconds instead, but we'd still be getting an odd ~500ms freeze randomly
  > >  Or we can just decide to move blocking or heavy algorithms to separate threads and enjoy our multicore computers and a fluid experience.
  >
  >
  > Where does the blocking happen? How do you guarantee none of the later call block? Large parts of the code are executed in the main thread anyway, only the initial list creation happens in a worker thread.
  
  
  listFromQuery is the big blocking call we are moving into a separate thread.
  
  > Also, if this is a generic problem, why only fix it in the dataengines, not in Solid itself?
  
  This would mean refactoring how Solid works and even coming up with entirely new concepts. I don't discard doing it at some point but I don't think plasmashell startup blockage is reason enough to redo a framework that has been working for about 5 years as is.

REPOSITORY
  R120 Plasma Workspace

REVISION DETAIL
  https://phabricator.kde.org/D22333

To: apol, #plasma, davidedmundson, bruns
Cc: bruns, plasma-devel, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20190711/de2c45a0/attachment-0001.html>


More information about the Plasma-devel mailing list