https://bugs.kde.org/show_bug.cgi?id=377067
Michael Pyne <mp...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
CC| |mp...@kde.org
Status|UNCONFIRMED |CONFIRMED
--- Comment #1 from Michael Pyne <mp...@kde.org> ---
I can confirm KConfig::sync()s are happening that appear to be needless, which
results in lock files being generated. This happens about 2-3 times for me on
startup which isn't "excessive" IMO but is definitely not optimal.
The fdatasync() are almost certainly intentional as part of QLockFile though,
but I think it would only be necessary as part of the 'stale lock' detection
(otherwise the contents of the lock file do not matter, only its presence in
the directory is important for locking). Removing the fdatasync and relying on
the FS's own data commit timing would be an upstream bug.
That still leaves the question of why the KConfig object is promptly becoming
dirty upon startup (the KConfig::sync method already avoids touching the disk
if it doesn't think a writeback is necessary), or whether a QLockFile is the
best anti-contention tool (maybe there's some kind of in-memory
processed-shared primitive that would work... though that way is fraught with
problems of its own).
--
You are receiving this mail because:
You are watching all bug changes.
