PDA

View Full Version : QObject sleep



TheGrimace
19th October 2007, 19:04
Is there a way to queue a msleep in the event loop of an object?

marcel
19th October 2007, 19:06
What do you mean?
Something like sending an event that tells the thread to sleep?

BTW, QOBjects don't have event loops. Only threads do.

TheGrimace
19th October 2007, 19:11
I have a QObject that is part of the main loop that is constantly doing a poll-like operation via the event-loop. I am wondering if there is a way to queue a 10 millisecond sleep for the main app so i am not using all my cpu.

marcel
19th October 2007, 19:14
Still, I don't think I understand:).

So you are analyzing all the events in the event loop... If you could post a user event with some ID, then when you get this event you could put the thread to sleep.

But you have to provide more details than that... For example, who is telling the thread to sleep? A worker thread?

TheGrimace
19th October 2007, 19:19
I have a main thread that receives signals from two worker threads. If a condition is not met when the main thread processes the signal, it resends the signal to itself via a queued connection. The problem is that I need to give the worker threads time to get things done before I process the event queue again. That way the condition might be met.

Thank You

TheGrimace
19th October 2007, 19:31
After writing about it more it seems my idea is flawed. Why is my object an object and not a thread? I think I will change that now. Thank you for your help.

marcel
19th October 2007, 19:48
I think that when you get a signal and it is too soon to process it(condition is not met) then you should queue the action, in a stack, list, array, whatever. By action I mean a structure or a class that holds enough information about what needs to be done.

Now, you could poll action list with a timer or even with another worker thread, and execute them as soon their conditions are met.

Your solution with resending the events doesn't sound that good.

TheGrimace
19th October 2007, 19:56
Thank You,

I agree. I am now rethinking my entire approach.

wysota
19th October 2007, 20:11
How about using a QTimer? There is probably no need to use threads...

TheGrimace
19th October 2007, 20:52
This is a side-question pertaining to the same code. If I have a widget which creates a thread, and if I then connect a signal from that thread to a slot in the same QThread object, to whom does the execution of that slot belong? The widget or the thread.

Edit: And by widget I mean an object or widget in the Main Application and not a thread

jacek
19th October 2007, 21:11
If I have a widget which creates a thread, and if I then connect a signal from that thread to a slot in the same QThread object, to whom does the execution of that slot belong? The widget or the thread.
The answer depends on the connection type (I assume you have automatic connections) and Qt version.

In Qt 4.2.3 automatic connections are handled this way:

// determine if this connection should be sent immediately or
// put into the event queue
if ((c->type == Qt::AutoConnection
&& (currentThreadData != sender->d_func()->threadData
|| c->receiver->d_func()->threadData != sender->d_func()->threadData))
|| (c->type == Qt::QueuedConnection)) {
::queued_activate(sender, *c, argv, from_signal_index, to_signal_index);
continue;
}
Which means that in this case the signal will be queued (first != operator returns true).

Edit: It appears that automatic connections always were handled this way.

TheGrimace
19th October 2007, 21:19
In this case i have been explicitly making queued connections. What I am wondering is, do the signals go into the thread's event queue or the main applications? I am using 4.3.1.

Thank You

jacek
19th October 2007, 21:29
What I am wondering is, do the signals go into the thread's event queue or the main applications? I am using 4.3.1.
Signals are queued in the event loop of the thread in which the receiver lives. Since you create the QThread instance in the main thread (a.k.a. the GUI thread), the signal will be stored in the main event loop, which means also that the slot will be executed by the main thread.

TheGrimace
19th October 2007, 21:33
So the only way to get a slot to execute in a thread is to make an object that is created in the thread? :( Darn!

Thank You for the information. :) These forums and you folks are a great help.

wysota
19th October 2007, 21:36
No, you can move an already existing object to another thread by using QObject::moveToThread. Just remember that you can only push the object from current to another thread, not pull it from another to current.

TheGrimace
19th October 2007, 21:38
So it would be something like:

thread->start();
thread->moveToThread(thread);

?

wysota
19th October 2007, 21:46
Yes, exactly like that. Just make sure the thread has no parent or it will not work. You can only move a parentless object.

TheGrimace
19th October 2007, 21:48
I just tried it and it worked like a charm :D No more gui freezing :)

Thank You!

jacek
19th October 2007, 22:26
Another solution is to simply pass Qt::DirectConnection as connection type, but you have create all QObjects in run().