{song,dir}vec_for_each each failed to gracefully handle deleted
files when iterating through. While we were thread-safe, we
were not safe within the calling thread. If a callback we
passed caused sv->nr to shring, our index would still increment;
causing files to stay in the database.
A way to test this is to remove 10 or so contiguous songs from a
>10 song directory.
We only need to lock sv->nr changes to prevent traversals ( why
it's called "nr_lock"). free(3) is a "slow" function on my
system; so we can avoid unnecessarily holding a lock long for
longer than needed.
Only one lock is used for all songvec traversals since
they're rarely changed. Also, minimize lock time and
release it before calling iterator functions since they
may block (updateSongInfo => stat/open/seek/read).
This lock only protects songvecs (and all of them) during
traversals; not the individual song structures themselves.
Our linked-list implementation is wasteful and the
SongList isn't modified enough to benefit from being a linked
list. So use a more compact array of song pointers which
saves ~200K on a library with ~9K songs (on x86-32).
