>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
--
Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16
Open Source Consulting Fax: +43/2243/26465-23
Reichergasse 131 www: http://www.runtux.com
A-3411 Weidling email: [EMAIL PROTECTED]
osAlliance member email: [EMAIL PROTECTED]
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
