bruns added a comment.
In D22333#494384 <https://phabricator.kde.org/D22333#494384>, @apol wrote: > 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. Again, where is it blocking? Which backend? >> 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. listFromQuery can be replaced by an asynchronous "enumerate(predicate)" call which uses the existing DeviceAdded signal. This would also remove the inherent race between the listFromQuery and DeviceAdded/DeviceRemoved. 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
