On 8 May 2012 20:49, Tom Breton (Tehom) <[email protected]> wrote: > * In principle we could re-merge some "mapped" classes with their "base" > counterparts. They spend a fair bit of code just staying in sync, or > trying to. But that's a lot of work and error opportunities just to keep > things working about the way they are.
This area is full of "historical" code that was originally designed to work with the GUI and sequencer in separate processes communicating through shared memory. Some of it was simplified (and/or thrown out) when the processes were merged in the Qt4 rebuild, but most is still there. But you still do have to be very careful with threading in this code. At the moment the mapped classes still have a distinct role as areas whose memory layouts are fixed and that are read-only on the sequencer-thread side, minimising the extent of necessary synchronisation when the structure contents change. If the sequencer used the base classes directly, we'd need much finer synchronisation, and that is difficult with the structures we're using. In fact, it's so difficult that one of the most significant causes of bugs has been improper synchronisation between readers and writers of our segment classes, _even where they are in the same thread and the same code unit_ -- e.g. in editing functions that iterate through a segment and modify some of the events in it. Mapped classes apart, the old process-communication structure gives rise to a lot of other things that make it difficult to follow the code and find bugs. For example, it's really tricky to work out who notifies who and how (in terms of classes, but also in terms of threads) when something changes like an audio file being loaded or a plugin setting being edited. The plugin architecture in general, from GUI through to audio I/O, is just crazily complex in a single-process world. > * What if we used garbage collection? I haven't looked at the Boehm GC for ages, but we did consider it for RG way back in the late 90s and rejected it as too unreliable in situations where some sort of competing object lifecycle management is already in place (as is usually the case in C++ and certainly when using Qt). Of course it's clear that we made plenty of wrong decisions about memory management, so perhaps that was one of them! But I'm pretty certain that it would be surpassingly difficult to introduce into an application with such tricky existing manual memory management as Rosegarden. One of the most significant and helpful changes made in Qt for Qt4 was the introduction of more consistent expectations for memory management of Qt objects. That is, except in special cases where you're expected to know what you're doing, QObjects are created on the heap, are not copied, are passed by pointer, and "belong" to their parent QObjects; non-QObject objects like strings and containers are created with automatic storage and passed by value using implicit copying. This sort of consistency wasn't a feature of Qt3 or KDE3 classes and it certainly wasn't ever a feature of Rosegarden's code. I suppose that one good principle might be to identify ways in which Rosegarden's model could be incrementally moved closer to modern Qt practice. Chris ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
