KConfig/KLockFile performance (was KMimeType performance)

Thomas Braxton kde.braxton at gmail.com
Thu Oct 11 13:02:16 BST 2007


On 10/10/07, David Faure <faure at kde.org> wrote:
>
> On Wednesday 10 October 2007, Thomas Braxton wrote:
> > On 10/9/07, Nhuh Put <nhuh.put at web.de> wrote:
> > >
> > > Von: Thomas Braxton
> > > Gesendet: Dienstag, 9. Oktober 2007 21:22
> > > An: kde-core-devel at kde.org
> > > Betreff: Re: KConfig/KLockFile performance (was KMimeType performance)
> > >
> > > > On 10/9/07, David Faure <faure at kde.org> wrote:
> > > > On Tuesday 09 October 2007, Maksim Orlovich wrote:
> > > > > KDesktopFile/KConfig tries to lock the file with KLockFile
> > > >
> > > > Huh. I thought we got rid of the "bool readonly" because it made no
> > > behavior difference,
> > > > but if KConfig locks the file then surely we need a "ReadOnly" flag
> > > again?
> > > > Or better: we should lock at the time of writing to the file, not
> when
> > > just reading from it!
> > > >
> > > > your mail came in as I was sending the last patch, here's another
> try.
> > > this time only locking in sync() and only if the file is read-write.
> > >
> > > This should work, but there is one problem: configState is only set to
> > > ReadOnly in
> > > KConfig::isConfigWritable, which is normally not called, so there
> should
> > > probably be
> > > a call to it in KConfigPrivate::changeFileName, or this will not have
> much
> > > effect.
> >
> >
> > I thought I already made that change, I must have forgot to commit it,
> > probably when I was having trouble getting a good update and had to get
> a
> > clean checkout
>
> I'm not sure what the current status is supposed to be (any uncommitted
> patch?),
> but I still see a lot of lock files created (or trying to be), both in
> /usr (no permissions) and in
> user-writable dirs (the lock file -can- be created, but why should it be,
> if we're only reading the file?)


sorry, didn't have time to commit yesterday, committed now.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071011/67ea6984/attachment.htm>


More information about the kde-core-devel mailing list