On sexta-feira, 27 de dezembro de 2013 14:00:38, Elvis Lee wrote: > But current problem is caused by QtDeclarative. Some object call > deleteLater, and it's loopLevel is '1' In threaded renderer of QtQuick, > there is an explicit call for sendPostedEvent(0, QEvent::DeferredDelete) > Unfortunately, our module is not on multi thread. So we need to call > sendPostedEvent(0, QEvent::DeferredDelete). Otherwise, we have to increase > loopLevel of the posted event as your patch. It assumes that we have to > modify opensource itself, right? > > I still couldn't decide which one is good approach. I have 2 candidates now. > 1. Add a glib func to do deferred deletion. The func will call > endPostedEvent(0, QEvent::DeferredDelete) > 2. Increase loopLevel for all > deleteLater. It will be implemented in QObject. (It's ugly. right?)
You're actually describing a bug (which is on-topic for dev@). As I said in my other email, there's a condition under which the loop level is 1. The level is incremented by 1 on entry to the new loop, plus 1 more when delivering events. But there are certain types of events (I don't remember which) that are delivered without the second increment -- probably directly delivered events inside QtQml and QtQuick, instead of using the regular mechanisms. Can you post a backtrace of the call to deleteLater(), when the loopLevel is 1? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
