apol added a comment.
Things we could do right now, without a super big refactoring: On a solid level: - Maybe a useful intermediate change would be to add API in Solid to move devices between threads. - Alternatively we could consider making sure backends stick to one specific non-GUI thread, keeping only 1 backend per application and have internals speak to it (admittedly a bigger refactoring). On a plasma level: - Keep Solid::Device::listFromQuery calls into a separate QThread and only extract tuples with the information we need rather than a Solid::Device (which was obviously faster but crashed because we can't move devices between threads). Either way, it's not a matter of KF5, adding new API is perfectly fine, problem is that we may end up redesigning both the frontend and the backend and this is far too much work right now. And so it will be when we're porting things to KF6. Also, I would suggest not really expecting to be able to do a nice, in-thread async API. Note that here we have exactly the same problem we have on plasma-nm and in Qt bearing networkmanager backend. It's hard to use these types asynchronously and we shouldn't go through hoops to make it thread-local. 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
