diff options
author | Eric Wong <normalperson@yhbt.net> | 2008-09-23 00:57:51 -0700 |
---|---|---|
committer | Eric Wong <normalperson@yhbt.net> | 2008-09-23 00:57:51 -0700 |
commit | efefaee1f9535012be2fbfea8f0f870904daad5d (patch) | |
tree | d0e5883697a993cc228e202dc033069cc32644e0 /src/utf8.c | |
parent | 8dc17ab196d30802b9a3c61dfef66c398ca01603 (diff) | |
download | mpd-efefaee1f9535012be2fbfea8f0f870904daad5d.tar.gz mpd-efefaee1f9535012be2fbfea8f0f870904daad5d.tar.xz mpd-efefaee1f9535012be2fbfea8f0f870904daad5d.zip |
directory: serialize freeSong() within the main thread
It's possible the playlist will be accessing a song that is to
be freed in the update thread. Rather than going through the
complexity (and potential to make mistakes) of locking the
playlist (as well as losing CPU cycles/pipelining due to
barriers with mutexes), we'll just line up all songs to
be freed in the main thread.
It's relatively uncommon to call freeSong() heavily (as it is to
update); so the extra, temporary memory usage won't be very
noticeable.
Additionally, if a song is renamed and it contains unique tag
item; this has the additional side effect of preventing
unnecessary fragmentation where an item is freed and shortly
reallocated.
Diffstat (limited to '')
0 files changed, 0 insertions, 0 deletions