WIP: Use a separate worker thread to run the actual deletion of files
AbandonedPublic

Authored by meven on Oct 18 2019, 9:47 AM.

Details

Reviewers
dfaure
Summary

Part of T11627

Diff Detail

Repository
R241 KIO
Branch
threadedDelete
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 17849
Build 17867: arc lint + arc unit
meven created this revision.Oct 18 2019, 9:47 AM
Restricted Application added a project: Frameworks. · View Herald TranscriptOct 18 2019, 9:47 AM
Restricted Application added a subscriber: kde-frameworks-devel. · View Herald Transcript
meven requested review of this revision.Oct 18 2019, 9:47 AM
meven updated this revision to Diff 68222.Oct 18 2019, 9:49 AM

Clean debug code

dfaure requested changes to this revision.Oct 20 2019, 10:30 AM

slotReport isn't the only problem, all of the subjob handling etc. seems very racy to me.

I suggest to start from scratch and write the smallest possible worker, whose only job is to delete a list of files, and report progress/completion via signal/slots or invokeMethod.

src/core/deletejob.cpp
161

This calls slotReport in the main thread, where it will read many values from the worker. Those values are written by the worker, from a secondary thread. This is the very definition of a race condition.

I thought the plan (in the task's pseudo-code) was to move into a worker, as little data as possible. And to never access that data from two concurrent threads.

In this patch, almost all of the members are moved to the worker, which creates race conditions all around.

I'm updating my "thread sanitizer" build of Qt and KIO to prove it, but I'm pretty sure :-)

180

Where is the corresponding delete statement?

This revision now requires changes to proceed.Oct 20 2019, 10:30 AM
meven abandoned this revision.Oct 26 2019, 11:50 AM

In favor of D24962