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

David Edmundson noreply at phabricator.kde.org
Tue Jul 16 23:20:22 BST 2019


davidedmundson added a comment.


  Kinda, you're summary missing a key part.
  (the commit description is a bit poor)
  
  This patch does the following:
  
  - It does the search in the other thread. That creates and iterates every possible device. This is expensive as there are lots of potential devices. We fetch pretty much everything udisks knows.
  
  - From the given list we recreate the select few devices that are relevant. This is relatively cheap. It does still block as you point out, but now for a much much smaller set of objects compared to before.
  
  (on my laptop that's 56 devices created when searching, resulting in 8 useful devices).
  
  This is where the main thread saving is meant to come in.
  
  As for dangling pointers. The private manager object dies as its backed by TLS. The device object itself does not. The device object has guards against a deleted manager internally. It won't crash, but will return "dead" values.
  
  ----
  
  You're absolutely right it's a hack around the current state, rather than a good long term direction. I'm not exactly loving it.
  I would love to rework solid to have a nice async api, and also to not use data engines. I'm not sure its doable within kf5.

REPOSITORY
  R120 Plasma Workspace

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

To: apol, #plasma, davidedmundson, bruns
Cc: anthonyfieroni, 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/20190716/82516ac4/attachment-0001.html>


More information about the Plasma-devel mailing list