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

2019-07-17 Thread Stefan Brüns
bruns added a comment. In D22333#496544 , @davidedmundson wrote: > 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

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

2019-07-16 Thread Aleix Pol Gonzalez
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 no

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

2019-07-16 Thread David Edmundson
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 potentia

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

2019-07-16 Thread Stefan Brüns
bruns added a comment. In D22333#494852 , @anthonyfieroni wrote: > https://phabricator.kde.org/source/solid/browse/master/src/solid/devices/frontend/devicemanager.cpp$301 > @bruns, It's backend per thread Yes, you are correct, so ther

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

2019-07-13 Thread Anthony Fieroni
anthonyfieroni added a comment. https://phabricator.kde.org/source/solid/browse/master/src/solid/devices/frontend/devicemanager.cpp$301 @bruns, It's backend per thread REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D22333 To: apol, #plasma, davidedmundson

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

2019-07-12 Thread Stefan Brüns
bruns added a comment. In D22333#494810 , @apol wrote: > In D22333#494774 , @bruns wrote: > > > Also, the code is calling non-threadsafe code from multiple threads now (e.g. once from each the two da

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

2019-07-12 Thread Aleix Pol Gonzalez
apol added a comment. In D22333#494774 , @bruns wrote: > Also, the code is calling non-threadsafe code from multiple threads now (e.g. once from each the two dataengines helper threads). Each one will call the udisks2 `Manager::deviceCache()` me

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

2019-07-12 Thread Stefan Brüns
bruns added a comment. In D22333#494415 , @apol wrote: > In D22333#494389 , @bruns wrote: > > > Again, where is it blocking? Which backend? > > > udisks2 mainly, but every backend can block by i

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

2019-07-11 Thread Aleix Pol Gonzalez
apol added a comment. In D22333#494389 , @bruns wrote: > Again, where is it blocking? Which backend? udisks2 mainly, but every backend can block by its virtue. > listFromQuery can be replaced by an asynchronous "enumerate(predicate)"

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

2019-07-11 Thread Stefan Brüns
bruns added a comment. In D22333#494384 , @apol wrote: > In D22333#494253 , @bruns wrote: > > > In D22333#494152 , @apol wrote: > > > > > In D22333#49414

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

2019-07-11 Thread Aleix Pol Gonzalez
apol added a comment. In D22333#494253 , @bruns wrote: > In D22333#494152 , @apol wrote: > > > In D22333#494146 , @bruns wrote: > > > > > Why not just a

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

2019-07-11 Thread Stefan Brüns
bruns added a comment. In D22333#494152 , @apol wrote: > In D22333#494146 , @bruns wrote: > > > Why not just a singleshot timer from the constructor? Avoids any initial blocking ... > > > Initi

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

2019-07-11 Thread Aleix Pol Gonzalez
apol added a comment. In 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

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

2019-07-11 Thread Stefan Brüns
bruns requested changes to this revision. bruns added a comment. This revision now requires changes to proceed. Why not just a singleshot timer from the constructor? Avoids any initial blocking ... REPOSITORY R120 Plasma Workspace REVISION DETAIL https://phabricator.kde.org/D22333 To: a

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

2019-07-09 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 61407. apol added a comment. Don't move Solid::Device instances between threads REPOSITORY R120 Plasma Workspace CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D22333?vs=61379&id=61407 BRANCH master REVISION DETAIL https://phabricator.kde.or

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

2019-07-08 Thread Aleix Pol Gonzalez
apol updated this revision to Diff 61379. apol added a comment. Call setFuture after connecting to finished REPOSITORY R120 Plasma Workspace CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D22333?vs=61372&id=61379 BRANCH master REVISION DETAIL https://phabricator.kde.org/D2233

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

2019-07-08 Thread Aleix Pol Gonzalez
apol created this revision. apol added a reviewer: Plasma. Herald added a project: Plasma. Herald added a subscriber: plasma-devel. apol requested review of this revision. REVISION SUMMARY They block the startup notably but the API doesn't require it to be blocking. TEST PLAN Ran plasmashell