aboutsummaryrefslogtreecommitdiffstats
path: root/src/songvec.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* tag: removed the "_ITEM_" suffix from the enum namesMax Kellermann2009-10-131-2/+2
|
* all: Update copyright header.Avuton Olrich2009-03-131-0/+19
| | | | | | | | This updates the copyright header to all be the same, which is pretty much an update of where to mail request for a copy of the GPL and the years of the MPD project. This also puts all committers under 'The Music Player Project' umbrella. These entries should go individually in the AUTHORS file, for consistancy.
* songvec: sort songs by disc and track numberMax Kellermann2009-01-151-0/+46
| | | | | Sorting songs by file name does not make much sense. Most of the time, users want to add songs in track order to the playlist.
* dirvec, songvec: sort using g_utf8_collate()Max Kellermann2009-01-151-1/+1
| | | | | | Path names in the directory and song structs are always encoded in UTF-8. Don't use strcmp(), it cannot handle UTF-8 characters properly. Use GLib's UTF-8 aware g_utf8_collate() function for that.
* songvec, dirvec: use GLib instead of utils.hMax Kellermann2009-01-031-8/+9
|
* songvec: migrate from pthread to glib threadsThomas Jansen2008-12-281-17/+29
|
* Remove xpthread_* wrappersThomas Jansen2008-12-281-0/+1
|
* update: fix multiple deletes from *vec iteratorsEric Wong2008-10-211-1/+5
| | | | | | | | | | | {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.
* {dir,song}vec: these structs are constEric Wong2008-10-211-1/+1
| | | | We definitely don't modify them here.
* {dir,song}vec: fix off-by-one errors in {dir,song}vec_deleteEric Wong2008-10-141-7/+6
| | | | | | | Found by Valgrind while looking for another bug... Hmm.. I should really just make this code generic since they're duplicated...
* songvec: avoid holding nr_lock during free(3)Eric Wong2008-10-131-3/+5
| | | | | | | 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.
* don't include os_compat.hMax Kellermann2008-10-081-0/+3
| | | | | When there are standardized headers, use these instead of the bloated os_compat.h.
* song: converted typedef Song to struct songMax Kellermann2008-10-081-11/+14
| | | | Again, a data type which can be forward-declared.
* songvec: pass const pointersMax Kellermann2008-10-071-2/+5
| | | | Pass const songvec pointers to songvec_find() and songvec_for_each().
* songvec: lock traversals for thread-safe updates/readsEric Wong2008-10-071-10/+34
| | | | | | | | | | 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.
* songvec: add songvec_for_each iteratorEric Wong2008-10-071-0/+13
| | | | | This is so we can more consistently deal with locking needed for thread-safety in iterator functions.
* songvec: songvec_delete takes a const Song pointerEric Wong2008-09-291-1/+1
| | | | We don't modify the Song when we delete it
* songvec_free => songvec_destroyEric Wong2008-09-291-1/+1
| | | | | "free" implies the songvec structure itself is freed, which is not the case.
* songvec: avoid free(NULL)Eric Wong2008-09-231-2/+4
| | | | Potentially broken free() implementations don't like it
* songvec: remove songvec_pruneEric Wong2008-09-231-23/+0
| | | | | | 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.
* Replace SongList with struct songvecEric Wong2008-09-231-0/+89
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).