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

Robin Burchell robin+qt at viroteck.net
Fri Dec 27 03:31:13 CET 2013

Hi Elvis,

On 27 Dec 2013, at 03:23, Elvis Lee(KwangWoong Lee) <kwangwoong.lee at lge.com>

I’m looking for good way to handle objects which have called deleteLater.
According to what I understood until now, there are 2 ways to handle them.
One is making control return to the event loop. Another is calling
QCoreApplication::sendPostedEvents(0, QEvent::DeferredDelete) explicitly.

Actually, for the first way, I couldn’t know what to do exactly in code
level. How to return control to event loop?

Let’s first think about how event based programming works.

A simple event loop might look something like this:

while (application_running) {
  // here we call out to user code
  // here control is back “in the event loop"

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.

  I feel the control is always on event loop in our module. Does that mean
to exit from event loop in QCoreApplication::exec()?

No. You shouldn’t have to.

So I tried the second way, calling sendPostedEvents explicitly. But I
encountered an obstacle to send the event.
It seems that the function should be called with lower or same ‘loopLevel’
of posted event.
I couldn’t find proper position to call sendPostedEvents except adding glib
function to main event loop. (We are using qeventdispatcher_glib)
Usually where is the good position to call sendPostedEvents with low

In sum, there are 2 question.
1.     What is the natural way to handle deleteLater?
2.     Where is a place which is not from QCoreApplication::notifyInternal
so that it has loopLevel ‘1’ to call sendPostedEvents?

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131227/285aabfb/attachment.html>

More information about the Development mailing list