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

Matthew Woehlke mw_triad at users.sourceforge.net
Thu May 28 17:28:53 CEST 2015


On 2015-05-28 01:22, Bo Thorsen wrote:
> The finished() signal on QThread - which thread do you expect this to 
> run in? And which thread would you expect a slot connected to it to run in?

I don't understand the question. I would expect that the signal is
executed in the QThread thread. I don't see how anything else is
possible unless some *internal* process causes an event to be queued in
some other thread telling that other thread (which must be running an
event loop?) to emit the signal instead. Is this the case?

> [...] you can only have a single reason left for 
> moveToThread(this): Signals and slots on the QThread. Refactor your code 
> and create another object that does all the work you put in the run instead.

I don't think you understand what I am actually doing.

I create an object in Thread 1 (e.g. the main thread). This object is
memory-owned by T1, i.e. it is expected that T1 will delete the object.
This object internally encapsulates a QThread, T2, to which it moves
itself upon construction. Slots belonging to the object are thus
executed in T2.

AFAICT this works fine, or at least I have yet to encounter any
noticeable issues with this approach. Am I missing something?

-- 
Matthew




More information about the Interest mailing list