> Date: Sun, 7 Nov 2010 13:14:26 +0100 > From: Maximilian Kossick <maximilian.koss...@googlemail.com> > Subject: Re: Re: [Amarok] b18a028: Use shared memory for collection > To: amarok-devel@kde.org > Message-ID: > <aanlktimd9ekbcssygkzjj1z=umzbpaenpfvgay=fj...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Sun, Nov 7, 2010 at 11:33 AM, Ralf Engels <ralf-eng...@gmx.de> wrote: > > snip > > > > Hi Jeff, > > the new scanner also skips the files where it crashed. > > > > I just needs to have a method to save the information about the bad > > files. > > The old version used a normal text file which might cause problems when > > the filenames have such stupid things as newlines in them. > > The my version used to use QSettings which turned out to be very slow. > > The very last version uses a shared memory which is both fast and (as > > taglib is not accessing the memory) also quite safe. > > An additional benefit is that several running scanners will not longer > > corrupt each others files. > > Ok, newlines might be a problem unless properly escaped, but I do not > think that we should start using shared meory just because QSettings > is slow. I'd suggest either going back to the previous method, or > writing to a XML file using QXmlStreamWriter. >
The whole dicussion is based on the assumption that shared memory is unsafe. I really can't see this. As a test I crashed the scanner several times with a division by zero just to verify that restarting works. No problem here. Also writing files during the scanning turned out to be slowing down the scanning a lot. The whole slow down that was reported by people (4 times) was just caused by the QSettings. It get's even worse when the files are already in the disk cache. Then it's more a factor of 40. Please prove me wrong. Using the scanner to scan /usr/share never crashed it (so taglib seems to be stable) and the shared memory should be safe from taglib even if it's going mad as the memory address is completely different from the other used segments. BR, Ralf _______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
