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. In what thread would a QObject be deleted if it was moved to another QThread?

In what thread would a QObject be deleted if it was moved to another QThread?

Scheduled Pinned Locked Moved Solved General and Desktop
deletelaterthreadevent loop
2 Posts 2 Posters 1.2k Views
  • 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.
  • L Offline
    L Offline
    LRDPRDX
    wrote on 10 Nov 2021, 11:25 last edited by
    #1

    The one can read here (emphs are mine) :

    The logging itself (LogWorker::logEvent) will always be done in the same thread, therefore this approach is working well for classes requiring thread-affinity. At the same time,LogWorker constructor and destructor are executed in the main thread (specifically the thread LogService is running in), and therefore ...

    I repeat the essential part of code here :

    class LogService : public QObject
    {
        ...
    private:
        QThread *thread;
        LogWorker *worker;
    };
    
    // implementation
    LogService::LogService(QObject *parent) : QObject(parent) {
        thread = new QThread(this);
        worker = new LogWorker;
        worker->moveToThread(thread);
        connect(this, &LogService::logEvent, worker, &LogWorker::logEvent);
        connect(thread, &QThread::finished, worker, &QObject::deleteLater);
        thread->start();
    }
    
    LogService::~LogService() {
        thread->quit();
        thread->wait();
    }
    

    Ok. It's obvious that the ctor is called in the main thread (we haven't moved the LogWorker yet). But what about the dtor? As stated in the documentation :

    [QThread::finished]

    When this signal is emitted, the event loop has already stopped running. No more events will be processed in the thread, except for deferred deletion events. This signal can be connected to QObject::deleteLater(), to free objects in that thread.

    and

    [Qt::QueuedConnection]

    The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.

    and

    [Per thread Event Loop]

    Calling delete on a QObject from a thread other than the one that owns the object (or accessing the object in other ways) is unsafe, unless you guarantee that the object isn't processing events at that moment. Use QObject::deleteLater() instead, and a DeferredDelete event will be posted, which the event loop of the object's thread will eventually pick up. By default, the thread that owns a QObject is the thread that creates the QObject, but not after QObject::moveToThread() has been called.

    According to this I would say the dtor must be called and executed in the secondary thread not the main one. Am I right?

    V 1 Reply Last reply 10 Nov 2021, 15:47
    0
    • L LRDPRDX
      10 Nov 2021, 11:25

      The one can read here (emphs are mine) :

      The logging itself (LogWorker::logEvent) will always be done in the same thread, therefore this approach is working well for classes requiring thread-affinity. At the same time,LogWorker constructor and destructor are executed in the main thread (specifically the thread LogService is running in), and therefore ...

      I repeat the essential part of code here :

      class LogService : public QObject
      {
          ...
      private:
          QThread *thread;
          LogWorker *worker;
      };
      
      // implementation
      LogService::LogService(QObject *parent) : QObject(parent) {
          thread = new QThread(this);
          worker = new LogWorker;
          worker->moveToThread(thread);
          connect(this, &LogService::logEvent, worker, &LogWorker::logEvent);
          connect(thread, &QThread::finished, worker, &QObject::deleteLater);
          thread->start();
      }
      
      LogService::~LogService() {
          thread->quit();
          thread->wait();
      }
      

      Ok. It's obvious that the ctor is called in the main thread (we haven't moved the LogWorker yet). But what about the dtor? As stated in the documentation :

      [QThread::finished]

      When this signal is emitted, the event loop has already stopped running. No more events will be processed in the thread, except for deferred deletion events. This signal can be connected to QObject::deleteLater(), to free objects in that thread.

      and

      [Qt::QueuedConnection]

      The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.

      and

      [Per thread Event Loop]

      Calling delete on a QObject from a thread other than the one that owns the object (or accessing the object in other ways) is unsafe, unless you guarantee that the object isn't processing events at that moment. Use QObject::deleteLater() instead, and a DeferredDelete event will be posted, which the event loop of the object's thread will eventually pick up. By default, the thread that owns a QObject is the thread that creates the QObject, but not after QObject::moveToThread() has been called.

      According to this I would say the dtor must be called and executed in the secondary thread not the main one. Am I right?

      V Offline
      V Offline
      VRonin
      wrote on 10 Nov 2021, 15:47 last edited by
      #2

      @LRDPRDX said in In what thread would a QObject be deleted if it was moved to another QThread?:

      the dtor must be called and executed in the secondary thread not the main one. Am I right?

      Correct, that's what connect(thread, &QThread::finished, worker, &QObject::deleteLater); does and as you noted>

      No more events will be processed in the thread, except for deferred deletion events.

      Do the deleteLater will still picked up after the finished is emitted and the destructor will run in the secondary thread

      "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
      ~Napoleon Bonaparte

      On a crusade to banish setIndexWidget() from the holy land of Qt

      1 Reply Last reply
      1

      1/2

      10 Nov 2021, 11:25

      • Login

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