| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Found by Valgrind while looking for another bug...
Hmm.. I should really just make this code generic since
they're duplicated...
|
| |
|
|
| |
We definitely don't modify them here.
|
| |
|
|
|
|
|
|
|
|
|
| |
{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.
|
| |
|
|
|
|
|
|
|
| |
This allows clients to see sorted results while we're
updating the DB and removes the need for us to have
to sort manually.
We'll have to write separate routines for managing stored
playlists with songvecs eventually; but that's for another day.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Pass const songvec pointers to songvec_find() and songvec_for_each().
[ew: already merged songvec_for_each() cosntification somewhere...]
|
| |
|
|
|
|
| |
Taming the directory.c monster, part II: move the database management
stuff to database. directory.c should only contain code which works
on directory objects.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Again, a data type which can be forward-declared.
[ew:
* used "struct mpd_song" instead to avoid token duplication
(like I did with "struct mpd_tag") as there's no good
abbreviation for "song" and identical tokens on the same
line don't read well
* rewritten using
perl -i -p -e 's/\bSong\b/struct mpd_song/g' src/*.[ch]
since it was too hard to merge
* also, I don't care much for forward declarations
]
|
| |
|
|
| |
Get rid of songvec_write so we can enforce proper locking
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This is so we can more consistently deal with locking
needed for thread-safety in iterator functions.
|
| |
|
|
|
|
| |
This make argument order more consistent for iterators.
Additionally, these now return ssize_t results for error
checking.
|
| |
|
|
| |
We don't modify the Song when we delete it
|
| |
|
|
|
| |
"free" implies the songvec structure itself is freed,
which is not the case.
|
| |
|
|
| |
Potentially broken free() implementations don't like it
|
| |
|
|
|
|
| |
Any pruned files will be noticed during update and pruned
from the live database, so this inefficient function can
go away and never come back.
|
|
|
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).
|
