Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Managing QThread/worker cleanup on destructor
Forum Updated to NodeBB v4.3 + New Features

Managing QThread/worker cleanup on destructor

Scheduled Pinned Locked Moved General and Desktop
1 Posts 1 Posters 724 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    rom1v
    wrote on last edited by
    #1

    Hi,

    The first exemple on this page "this page":http://doc.qt.io/qt-5/qthread.html#details embed an object QThread in a class Controller. Therefore, it is forced to call wait() in ~Controller, else the QThread object would be destroyed too early.

    On the same documentation page, some § later:
    Note: wait() and the sleep() functions should be unnecessary in general, since Qt is an event-driven framework. Instead of wait(), consider listening for the finished() signal.

    I totally agree with that. If I use a thread, this is probably because I don't want to freeze the UI. Calling a wait() in the ~Controller() could freeze, so IMO it is a very bad idea. Therefore, I think it is better to use a QThread* in Controller instead, and to connect &QThread::finished to &QObject::deleteLater for both the worker and the workerThread.

    That way, the controller destructor can complete without waiting, and the worker/workerThread will be deleted when possible. And that works fine…

    Except on program termination. If the controller destructor is called due to program termination, then the event loop is stopping, so the deleteLater slots would never be called. We may say "we don't care, the program terminates", but it seems deficient; in theory, we could still want to execute the worker/workerThread destructors at the end of the program (and it would avoid valgrind to report a lot of memory leaks).

    What do you think?

    1 Reply Last reply
    0

    • Login

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Get Qt Extensions
    • Unsolved