| Commit message (Collapse) | Author | Age | 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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Like the songvec nr_lock, only one lock is used for all
traversals since they're rarely changed. This only
projects traversals, but not the individual structures
themselves.
|
|
|
|
| |
This will make it easier to introduce locking
|
|
|
|
|
| |
dirvec_find() does not modify the object, thus it should get a const
pointer.
|
|
|
|
|
|
|
|
| |
CamelCase is ugly, rename the functions.
[ew: "directory_get_directory" was too confusing, using
"directory_get_subdir" instead (old function was named
"getSubDirectory")]
|
|
|
|
|
| |
The struct can be forward-declared by other headers, which relaxes the
header dependencies.
|
|
Having all functions as static (non-inline) functions generates GCC
warnings, and duplicates binary code across several object files.
Most of dirvec's methods are too complex for becoming inline
functions. Move them all to dirvec.c and publish the prototypes in
dirvec.h.
|