Remove queued callbacks when object is destroyed?

[Vadim Lebedev]

Maybe we should introduce  some kind of reference counting?


Thanks
Vadim

Ralf Schlatterbeck wrote:
> >From my tracker item http://trac.qutecom.com/ticket/6 I'll repeat the
> question here:
> Looks to me that SipAccount::connectionIsDownEventHandler is called
> while the SipAccount is still valid. This schedules a callback which
> arrives when we already have a dangling reference. I'm at a loss here
> how to change this to a saner behaviour (and the course of events is
> only a guess but I've seen similar things at other occasions in
> qutecom). Can we somehow remove scheduled callbacks when the object is
> destroyed?
>
> This refers to the usual pattern in Qutecom, something like 
>
> void SipAccount::connectionIsDownEventHandler(NetworkObserver & sender) {
>         typedef ThreadEvent0<void ()> MyThreadEvent;
>         MyThreadEvent * event =
>                 new MyThreadEvent(boost::bind(&SipAccount::connectionIsDownEventHandlerThreadSafe, this));
>
>         WengoPhone::getInstance().postEvent(event);
> }
>
> void SipAccount::connectionIsDownEventHandlerThreadSafe() {
>         Mutex::ScopedLock lock(_mutex);
>
>         _initTimer.stop();
> }
>
> Here the callback to connectionIsDownEventHandlerThreadSafe is queued in
> connectionIsDownEventHandler. But it can happen that when calling
> connectionIsDownEventHandler the SipAccount Object is already dead. Is
> it possible to unqueue callbacks on object destruction (In this case the
> timer is dead, too, so it doesn't need to be stopped anyway)
>
> Ralf
>