Fix a race on the 'abort' variable. While there was a mutex lock around
the code that sets the variable in ~QFileInfoGatherer, there was no
protection in getFileInfos(), where it is read:
// T:this->thread() // T:*this
// in getFileInfos(), after last mutex.unlock()
mutex.lock();
abort = true; while (!abort...
// ... // ...
Fix by making 'abort' an atomic. This means that we can drop the mutex
locker in the destructor, too. We still mostly access 'abort' under
protection of the mutex, because we need to protect other variables that
just happen to be accessed together with 'abort', but we avoid the mutex
lock/unlock on each iteration of the while loop in getFileInfos().
Also cleaned up the logic in run():
- by using the canonical form of condition.wait() (in a loop that
checks the condition), we can ensure that !path.isEmpty() and avoid
having to use the updateFiles boolean.
- by checking for abort.load() after we return from
condition.wait(), we minimise the waiting time for thread
exit.
- by using different local names, we avoid having to this->qualify members.
Also changed one condition.wakeOne() to wakeAll() for consistency
with fetchExtendedInformation().
Change-Id: If35f338fe774546616ec287c1c37e2c32ed05f1a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
6d9d2c4fa8