Albert Santoni wrote: > 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? > > A quick look at all the classes which have member variables which store references to TIO's indicates to me that we're going to need many more mutexes than just those 2.
I'm kind of against adding an explicit lock per instance of thing that uses the TIO. I think it'd be better if we added a generic reference count to the TIO that you could increment() and decrement(), not set()/get(). All places in Mixxx which store a pointer to the TIO (the analyserqueue, the waveform, the player, the reader, the engine, etc) would increment() once they receive the TIO (and store a pointer to it), and decrement() once they are done with it and have erased all references to the pointer. The player, reader, and waveform would all automatically decrement() once a new track is loaded, so those would never cause dangling references. We could even make it delete itself once its reference count drops to 0. An alternative way of doing this is to use QSharedPointer, which would lock us into requiring Qt 4.5. I'm also wary of using this because not every reference to the TIO is worthy of reference counting. Disregarding the large amount of work that would need to go into replacing every TIO pointer with a QSharedPointer, this is not a bad plan. In either case, we would make the TIO destructor emit a signal like aboutToDelete() and then delete itself. The thing that created the TIO would connect this signal to some slot it has and do whatever logic it needs to to clean up after it (e.g. the TrackCollection would serialize the TIO's relevant data to the database). This way whatever source created the TIO in the first place knows which TIO's are resident in memory and which have been gc'd so they can hand out new references to the existing TIO on request, or load it from wherever (eg the database). > 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. > > I kind of think we should just let the queue finish instead of adding logic to let it exit early. The reference counting approach above would mean it is automatically deleted when its count reaches 0, so we wouldn't really need to worry about when to delete the TIO and who should delete it / how can it send the right message to all appropriate parties that it is time to get rid of all your references to it, etc. That is a complicated dance. Our problem would just become making sure that no part of Mixxx keeps dangling references to TIO's after it is done with them. > If anyone wants to share their ideas or criticism, it would be greatly > appreciated. > > Thanks, > Albert > RJ ------------------------------------------------------------------------------ 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
