Russell Ryan a écrit : >> > 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).
I hadn't time to dive into mixxx's codebase, although it's many month now that i'd like to, so this may be completly off-topic, but the problem here is, as far as i understand, typically what std::tr1::shared_ptr/std::tr1::weak_ptr are designed for. Looks like the player should use a shared_ptr, while the other components of mixxx should store weak_ptr on this instance. This would not require any additional run-time dependancy, but would still require to change any pointer to a TIO into a shared or weak_ptr. regards, Julien ------------------------------------------------------------------------------ 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
