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 > _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
