Code review comment for lp:~mir-team/mir/fix-1339700

Cross post from the 0.4 merge:

Hm. This would appear to be a bandaid solution. The underlying problem is that Alarm is calling out to code it doesn't control while holding a lock; we can't guarantee correct locking in this case.

This was introduced in https://code.launchpad.net/~alan-griffiths/mir/fix-1334287/+merge/224457, which fixes a bug, so we can't simply drop the lock. We might need a second lock in AlarmImpl guarding the destructor and data->callback() call?

I'm not averse to this as an urgent fix, but unless we also fix it properly this sort of timebomb will keep exploding :)