Hi Robin, > So, your application code will be invoked when there is something to respond > to (an event) - like a timer, socket activity, user > input, etc. When that is done, the control has returned to Qt, and Qt goes > back to sleeping, waiting for new events.
> At some point (I’m not sure if it’s defined when - before or after invoking > the user code), Qt processes deferred deletion. Right. I hoped that Qt(QtBase) do deferred deletion automatically when it get back to the event loop. But it didn't. For the precision, it tried, but it couldn't. If the original intention is that normal sendPostedEvent do the deferred deletion, now I feel that this is a problem related with loopLevel of posted DeferredDelete event as your patch. > If this is related to QtWayland: you may be running into a bug within Qt > which we also hit. See the WIP patch > at https://codereview.qt-project.org/#change,71892. Unfortunately, we haven’t > gotten things fixed for all dispatchers yet, > so it isn’t yet merged. Maybe the patch will be helpful for us because we are also using QtWayland. 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?) Thanks. Elvis. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
