String::detach() not thread-safe?

[Kevin André]

Hi Scott,

On Sat, Nov 15, 2014 at 2:46 PM, Scott Wheeler <wheeler at kde.org> wrote:
>
>> On Nov 15, 2014, at 1:59 PM, Kevin André <hyperquantum at gmail.com> wrote:
>>
>> With some googling I learned that multithreading issues in taglib were
>> discussed before […]
>
> Originally TagLib was never intended to be thread safe.  Little bits have
> been added over time, but they’ve mostly been band-aids.  At the time
> the main reason for that was that it didn’t make sense to use TagLib
> from multiple threads:  for reading from a hard disk, it’s a bad idea to
> read using multiple threads.  Tag reading isn’t CPU bound except when
> all of the data is already in disk buffers and for disk IO, you’ll get worse
> performance by doing heavy reading from multiple threads (it’ll increase
> the number of seeks).  I don’t know if this has changed with SSDs, but
> it’d be worth benchmarking before assuming “more concurrent threads”
> == “faster” in your application.  (Remember to purge the disk buffers
> before testing.)

Well in my case it's not just tag reading. An mp3 file is processed as follows:

  1) read the whole file into memory
  2) read the tags
  3) strip all tags from that in-memory file copy (this is a slow
operation, right?)
  4) calculate SHA-1 and MD5 of the bytes remaining and store those in
the database, along with the tag data
  5) discard memory

For each file to be indexed, a QRunnable instance is created which
receives the path to the file and then proceeds to do those 5 steps.

There is no sharing of any TagLib class instances between different
threads (tasks) in my application code, so multithreaded use would be
fine as long as TagLib wouldn't do any sharing of its own. But if it
has any static class members (like String::null), then those need to
be thread-safe :-/


Regards,

Kevin