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