Planned maintenance has been done but it did not solve the problem. So work will continue on this and a new time for trying updates will be announced asap.

What if quit event loop with events in the queue?



  • For example, there are many event in the event loop waiting to handle, then quit() the event loop before all the events are handled, what about the events that not handled yet?



  • @jronald
    I imagine they are left unhandled...


  • Lifetime Qt Champion

    Hi,

    What kind of event do you have in mind ?


  • Moderators

    @jronald I think the events are handled in the order they are received. Haven't double checked the source to prove this though so I could be wrong.

    In that case anything after quit() will be ignored/dropped. If the events were before the quit they will be handled.



  • @SGaist any, especially that cause memory leaking


  • Moderators

    @jronald None of the events that aren't handled should cause a leak. However if you were to call a deleteLater to clean up objects after the loop has exited that event will not get handled and thus could leak.

    That would be caused by you though and not the QEvents in the event loop.



  • @ambershark Yes, something like deleteLater() to delete objects in a working thread in a way of Qt::QueuedConnection, then for example at some random time the user clicked a button to cause the working thread to quit() its event loop. If this may leak memory, the problem is:

    1. when deleteLater() is called, my code is out of control of the object
    2. quit() is called at a random time, also out of control

    How to control to forbidden memory leak in this situation?


  • Moderators

    @jronald I read the docs on deleteLater, here they are for reference:

    The object will be deleted when control returns to the event loop. If the event loop is not running when this function is called (e.g. deleteLater() is called on an object before QCoreApplication::exec()), the object will be deleted once the event loop is started. If deleteLater() is called after the main event loop has stopped, the object will not be deleted. Since Qt 4.8, if deleteLater() is called on an object that lives in a thread with no running event loop, the object will be destroyed when the thread finishes.

    Note that entering and leaving a new event loop (e.g., by opening a modal dialog) will not perform the deferred deletion; for the object to be deleted, the control must return to the event loop from which deleteLater() was called.

    Note: It is safe to call this function more than once; when the first deferred deletion event is delivered, any pending events for the object are removed from the event queue.

    It looks like your main thread would handle the deleteLater if your worker thread exited without cleaning up the objects. So that probably isn't where your memory leak is.

    You can try an application like valgrind to figure out where it is leaking.



  • @ambershark OK, I'm studying Qt, maybe there will be an answer later, if there isn't, I'll check it out practically. Thanks.



  • @ambershark said in What if quit event loop with events in the queue?:

    It looks like your main thread would handle the deleteLater if your worker thread exited without cleaning up the objects. So that probably isn't where your memory leak is.

    You can try an application like valgrind to figure out where it is leaking.

    Maybe QThread::exit() and QThread::quite() take care of this before end the event loop.


  • Moderators

    @jronald From the sounds of it, after rereading your posts above, when quit() is called on your thread it should clean up your objects for you. I don't think that's where you are leaking memory.

    Again something like valgrind could help you figure out where you're leaking.


Log in to reply