No subject

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: office at runtux.com
osAlliance member                       email: rsc at osalliance.com