[Amarok] b18a028: Use shared memory for collection

[Ralf Engels]

> Date: Sun, 7 Nov 2010 13:14:26 +0100
> From: Maximilian Kossick <maximilian.kossick at googlemail.com>
> Subject: Re: Re: [Amarok] b18a028: Use shared memory for collection
> To: amarok-devel at kde.org
> Message-ID:
> 	<AANLkTimD9EKbcsSYGkzjJ1Z=umzbPAENPfvGaY=fjH77 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On Sun, Nov 7, 2010 at 11:33 AM, Ralf Engels <ralf-engels at 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