aboutsummaryrefslogtreecommitdiffstats
path: root/src/songvec.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* 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).
generated by cgit v1.2.3 (git 2.25.1) at 2024-10-28 23:45:08 +0000