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