search

jamoma / JamomaCore

Jamoma Frameworks for Audio and Control Structure
Other
37 stars 14 forks source link

Address weakness in notification/observer system #353

Open tap opened 9 years ago

tap commented 9 years ago

Over the years both @theod and I have been bitten some really difficult to track bugs stemming from pointers going out of scope or leaking in the observer and notification system. This is still at the heart of our worst AudioGraph problems that we need to solve.

I have two insights that together could revolutionize our system:

  1. From C++11 smart pointers -- Objects being observed are all shared pointers. The objects that issue notifications can track them using weak pointers, which know when the underlying object goes away!
  2. RAII -- An observer (let's call it TTObserver, assuming that name isn't taken) should be a class of it's own. An object which wishes to observe another object should create an instance of TTObserver. Then when it goes out of scope everything cleans up after itself neatly, unlike the wild west manual cleanup that happens currently (and problematically in some cases).

This implies that TTObject ref counting and other "smart pointer" stuff which we have implemented manually migrate to standard C++ smart pointers.

theod commented 9 years ago

+1 for smart_pointers ! and I never seen any object called TTObserver. Is this class isn't relative to the TTCallback class (which can be used to observe notifications send from another class) ? is the TTCallback will still be useful ?

theod commented 9 years ago

I also mention that for the time being if I change an attribute I have to take care to notify its observers (which is normal but a bit convoluted : see here in TTData::notifyObservers)).

theod commented 9 years ago

And finally why we don't have TTNotification class for a TTObject like we have TTAttribute and TTMessage ?

this would match the Max concept of parameter, message and return and maybe allow to move them directly at the TTObject level (for the record we currently need to create a TTData with @service equal to "parameter", "message" or "return"). Of course this will implies to move all the TTData internal processings inside what we call the TTAttribute "properties" with a smart design pattern to allow to choose which kind of processing we want to make on the values (repetition filtering, ramping, ...).

is this make sense for you @tap ?