Code review comment for lp:~albaguirre/mir/avoid-surf-observer-deadlocks

There's an issue with this approach:

Currently client code can assume that a callback cannot occur after it has been removed by remove_observer(). This is convenient, e.g. when destroying the object that needs notifications to ensure notifications are not sent to dead objects.

With this proposal this expectation no longer holds: after the copy & release of mutex in for_each() another thread may remove a listener before the callback is invoked.

As far as I can see there must be a mechanism to synchronize invoking a listener and removing it from the collection. (A recursive lock is possibly the least obtrusive but needs to ensure removal is associated with called listener to be entirely safe.)

We've hit issue in callback registrations before (racarr and anpok have had MPs discussing it) - I'm wondering if there's a good design "out there" that covers all needs.