Non-Gui thread blocking gui

[wysota]

It may behave incorrectly because you are emitting the signal to the thread object. And the thread object lives in the same thread as the calling object (only objects created within run() or from within methods called from the thread's event loop live in the worker thread), so the slot might be called by the wrong (main) thread. It could be possible that all you need to do is to wait until the thread is started before emitting the signal (but you have to explicitely use queued connections for that to work!) - that would explain why subsequent signals work correctly.

connections.at( i )->start( QThread::NormalPriority );
while(!connections.at(i)->isRunning()) QThread::sleep(100); //crude, but should work

connections.at( i )->start( QThread::NormalPriority );
while(!connections.at(i)->isRunning()) QThread::sleep(100); //crude, but should work

To copy to clipboard, switch view to plain text mode 

[Valheru]

Would the custom event run in the worker thread? I'd prefer to do it that way if it is so, I'm busy restructuring the program now to make it cleaner and fix bugs so I don't want to hack some half-assed fix in if at all possible

[wysota]

Would the custom event run in the worker thread?

Yes, but with the same condition - make sure the thread is already running its event queue (as this probably moves the thread object to the thread itself) before posting the first event.

[jpn]

In Qt 4, a slot in a QThread subclass ends up being executed in the thread where the QThread object itself is living in (QObject lives in the thread where it was created).

A signal and slot connection is direct between objects living in the same thread. So if a QThread object is instantiated in the main GUI thread, the QThread object itself also lives in the main GUI thread. And so the connection is direct and the slot in a QThread subclass ends up being executed in the main GUI thread aswell.

You can avoid all this by simply creating a QObject in QThread::run() and connecting signals to that object instead of the QThread object. This ensures that the signal slot connection is across thread.

[jpn]

The behaviour is exactly the same with posting events. The event gets processed in the event loop running in the thread where the receiver object lives in. Since the QThread object lives in the main thread, it's customEvent() gets executed in the main thread as well.

[wysota]

Hmm, it doesn't seem to like being passed an int as argument for the creator of QEvent. Would it be safe to statically cast it to QEvent::Type?

Yes.

The behaviour is exactly the same with posting events. The event gets processed in the event loop running in the thread where the receiver object lives in. Since the QThread object lives in the main thread, it's customEvent() gets executed in the main thread as well.

Hmm... I thought exec() moves the object into the thread. If it doesn't, it should be enough to move it inside run():

void MyThread::run(){
  moveToThread(this);
  exec();
}

void MyThread::run(){
  moveToThread(this);
  exec();
}

To copy to clipboard, switch view to plain text mode 

[jpn]

Hmm... I thought exec() moves the object into the thread. If it doesn't, it should be enough to move it inside run():

void MyThread::run(){
  moveToThread(this);
  exec();
}

void MyThread::run(){
  moveToThread(this);
  exec();
}

To copy to clipboard, switch view to plain text mode 

Good idea, but seems to be not possible:

QObject::moveToThread: Current thread (003E7CA0) is not the object's thread (0012FEC4).
Cannot move to target thread (0012FEC4)

I tested with both

moveToThread(this);
// and
moveToThread(QThread::currentThread());

moveToThread(this);
// and
moveToThread(QThread::currentThread());

To copy to clipboard, switch view to plain text mode 

[chca]

Good idea, but seems to be not possible:


I tested with both

moveToThread(this);
// and
moveToThread(QThread::currentThread());

moveToThread(this);
// and
moveToThread(QThread::currentThread());

To copy to clipboard, switch view to plain text mode 

I had the same problem, but when you call "moveToThread" in the class' constructor (which is executed in the thread the object is created in), it seems to work.

[Valheru]

Hmm, it doesn't seem to like being passed an int as argument for the creator of QEvent. Would it be safe to statically cast it to QEvent::Type?

connection.h:35: error: invalid conversion from ‘int’ to ‘QEvent::Type’

connection.h:35: error: invalid conversion from ‘int’ to ‘QEvent::Type’

To copy to clipboard, switch view to plain text mode