| Commit message (Collapse) | Author | Files | Lines |
|---|
|
Blindly destroying these without freeing the underlying
elements was a bad idea, always. Our iterators suck
less nowadays and we can traverse them and free() each
element safely.
|
|
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.
|
|
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
|
|
This is so we can more consistently deal with locking
needed for thread-safety in iterator functions.
|
|
We don't modify the Song when we delete it
|
|
"free" implies the songvec structure itself is freed,
which is not the case.
|
|
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).
|
