meven added a comment.
In T11627#218943 <https://phabricator.kde.org/T11627#218943>, @meven wrote: > In T11627#206210 <https://phabricator.kde.org/T11627#206210>, @broulik wrote: > > > I'm pretty sure there's a tonne of blocking DBus calls being done all over the place during file copy (checking for slaves on hold, updating kuiserver job tracking info, etc) which can cause apps to hang or slow down if whatever they're trying to call into is busy. Best example: SIGSTOP plasmashell, try copying a file in Dolphin, won't work until plasmashell SIGCONTs. > > > That's interesting, we need to fix that. > > About https://bugs.kde.org/show_bug.cgi?id=281270 `Inconsistent notifications during/after file operations (copying, moving, deleting, compressing, extracting) depending on amount of data/items involved` : > > A possible way to fix this would probably use sendfile with O_NONBLOCK + select. > After a non-blocking sendfile we call select/pselect on the dest file descriptor. Then when it returns something other than EWOULDBLOCK, we can deduce the processed bytes from the size sent to copy to dest (i.e sendfile count parameter) or use pselect and its sigset_t parameter. We then can call sendfile again to write next bytes. > On the plus side it would make the code async which would make progress reporting more reactive. This approach does not work unfortunately, select does not take into account filesystem sync. I tried also with `sync_file_range` but it does not block when file is syncing. That being said the select method allows to free some main thread cpu time while the kernel is running sendfile. Allowing for instance to notify ioslaves users of progress. Regarding this bug I have the idea of adding a state "Closing file" or "Writing data to disk" to the CopyJob so users can surface to users that something is going on. And I want to edit D25079 <https://phabricator.kde.org/D25079> where the chunk size for sendfile is probably too big. TASK DETAIL https://phabricator.kde.org/T11627 To: meven Cc: broulik, ognarb, #dolphin, #frameworks, meven, dfaure, pberestov, iasensio, fprice, LeGast00n, MrPepe, fbampaloukas, alexde, GB_2, Codezela, feverfew, michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, mikesomov
