While Sean pointed out that some of this conversation is moot in light of the 1.8 library rewrite, there's still a problem of TIO persistence that we have in 1.8.
Whenever a new song is loaded into a player, we currently (in 1.8) grab that song's data from the database and dump it into a TIO. What I'd like to do is free each TIO when it gets unloaded from a player, but unfortunately the analyser queue could still be processing that TIO. An easy way to get around this is to set up two mutex-protected flags inside TIO: One which indicates if the TIO is loaded into a player, and the other that indicates if the TIO is being analysed. If the track is unloaded from a player and it's not being analysed, then we know it is safe to delete. If the track hit the end of analysis and it's not loaded into a player, then it is also safe to delete. In all other cases, someone is still using the TIO and it should not be deleted. Does anyone see any problems with this? Another way we could do it is to refactor AnalyserQueue to start and stop it's thread for each TIO it's going to analyse. If a track gets unloaded from a player, we could tell the AnalyserQueue to either remove that track from the queue or kill the analysis thread if it's currently being processed. At that point, it should be safe to free the TIO. If anyone wants to share their ideas or criticism, it would be greatly appreciated. Thanks, Albert ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
