[Interest] Poor QMethod::invoke performance across threads on i.MX53

[Matthew Woehlke]

On 2015-05-27 16:41, Thiago Macieira wrote:
> On Wednesday 27 May 2015 15:02:36 Matthew Woehlke wrote:
>> On 2015-05-18 03:46, Thiago Macieira wrote:
>>> On Thursday 14 May 2015 18:18:52 Robert Daniels wrote:
>>>>         moveToThread(this);
>>>
>>> This is wrong. Never do "moveToThread(this)", since it's very difficult to
>>> then destroy the QThread object. This is unrelated to the problem and
>>> it's probably only for simplicity of your testcase.
>>
>> Sort of OT, but... why? If the object in question is destroyed by the
>> same thread that created it, after the thread that the object
>> "represents" has terminated cleanly, what is the problem?
> 
> The problem is a QThread living inside the thread that it started.
> 
> You can't destroy that object inside that thread because the QThread 
> destructor will wait() until the thread exits. And the thread can't exit until 
> the destructor has returned. That's a deadlock.

Right. An example probably helps. What's wrong with this approach?

  class MyThread : public QThread { ... } // has moveToThread(this)

  int main()
  {
    auto* t = new MyThread;
    t.start();
    // ...
    t.wait();
    delete t; // QThread deleted from main thread, not itself
  }

The QThread is memory-managed from a thread other than itself. It's just
that the thread affinity is circular. Note that I am *NOT* trying to
deleteLater the QObject! (Because, yes, that would be horrible! And for
that matter, would leak, since in my usage, the thread has exited before
I try to delete it.)

Anyway, a more accurate depiction of my case is:

  class MyThread : public QObject
  {
    QThread self;
    MyThread() { moveToThread(self); }
  }

...where again, it is assumed that MyThread is deleted from a thread
other than MyThread::self. Is this approach broken? (I think no? It
seems similar to the alternate approach you gave.)

-- 
Matthew