aboutsummaryrefslogtreecommitdiffstats
path: root/src/storedPlaylist.h
diff options
context:
space:
mode:
authorEric Wong <normalperson@yhbt.net>2008-09-23 00:57:51 -0700
committerEric Wong <normalperson@yhbt.net>2008-09-23 00:57:51 -0700
commitefefaee1f9535012be2fbfea8f0f870904daad5d (patch)
treed0e5883697a993cc228e202dc033069cc32644e0 /src/storedPlaylist.h
parent8dc17ab196d30802b9a3c61dfef66c398ca01603 (diff)
downloadmpd-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 'src/storedPlaylist.h')
0 files changed, 0 insertions, 0 deletions