[Development] [Q] Good way to handle QEvent::DeferredDelete

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131228/4c96beb9/attachment.sig>