[Amarok] b18a028: Use shared memory for collection

[Ralf Engels]

> Message: 1
> Date: Sat, 06 Nov 2010 09:03:34 -0400
> From: Jeff Mitchell <mitchell at kde.org>
> Subject: Re: [Amarok] b18a028: Use shared memory for collection
> 	scanner to	rememb
> To: maximilian.kossick at gmail.com, amarok-devel at kde.org
> Cc: kde-commits at kde.org
> Message-ID: <4CD55226.9030406 at kde.org>
> Content-Type: text/plain; charset="utf-8"
> 
> On 11/06/2010 05:38 AM, Maximilian Kossick wrote:
> > One of the reasons for collection scanner as a separate executable was
> > to prevent a crash in collectionscanner from bringing down Amarok as
> > well. As both processes only communicated with each other via files or
> > stdout/stdin, this was relatively safe. Is it ensured that a
> > corrpution of the shared memory data does not crash both processes?
> 
> This is especially important as TagLib has a history of being quite
> crashy on corrupted files (which are quite common). (The old ScanManager
> tried to skip such files if the scanner was crashing on a particular
> file (with mixed success) by restarting the scanner.)
> 
> --Jeff
> 

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.

Also while playing around with taglib I never encountered a crash
directly caused by taglib.
If it weren't for the batch mode I would recommend to forget about a
seperate scanning process.

Also since File.cpp and AFTUtil.cpp is directly using taglib they will
run into the same taglib problems. So a potential crash is not prevented
but only less likely.

BR,
Ralf