markg added a comment.
In D10702#273040 <https://phabricator.kde.org/D10702#273040>, @meven wrote: > Great suggestion Mark ! > > I am a C++ beginner, I did not consider this neat C++ 14 feature. > > This will necessitate a c++ compiler dependency change though. > Like Kwin did last July https://github.com/KDE/kwin/commit/ea5d611de1bc33869c13c27d75a7827201a5139d Well, it's nearly all C++11 :) Only the "300ms" (specifically the "ms") in there is new in C++14 (chrono literals: https://en.cppreference.com/w/cpp/chrono/duration). In this case removing the ms would make it C++11 and probably work (i haven't tested that). You could make it all in Qt (QThread, QFuture, ...). I'm just not that used to those classes en went for the STL ones instead. > > >> That in it's own is slightly different to what the code currently does. Currently it calls slotReport after every 300 files. With this it would call slotReport after every 300ms. I don't think that's much of a problem. > > I think a time based update would make more sense to the user. > > I think deleteFiles and deleteDirs should both be wrapped in the async function. > Otherwise, at best we would end up with multiple parallel file deletion which is not preferable (given current filesystems and hardware, we should favor sequential deletion) and at worst the same as today blocking the main thread. > Or we might need some mutex/buffer to synchronize the unlink syscalls through Qt::remove() between different async deletion functions. > > So this plus the added necessary synchronizing code, this might end up a big code change. Take care with modifying those class members though. You'd probably want to protect them with a mutex. Even though this code probably won't cause a race condition, better be safe then sorry :) > I will give a spin. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D10702 To: meven, #frameworks, dfaure, ngraham, #dolphin, jtamate Cc: kde-frameworks-devel, jtamate, markg, ngraham, #frameworks, michaelh, bruns
