QObject sleep

[TheGrimace]

Is there a way to queue a msleep in the event loop of an object?

[marcel]

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]

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]

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]

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]

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]

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]

Thank You,

I agree. I am now rethinking my entire approach.

[wysota]

How about using a QTimer? There is probably no need to use threads...

[TheGrimace]

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]

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;
}

// 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;
}

To copy to clipboard, switch view to plain text mode 

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]

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]

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]

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]

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]

So it would be something like:

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

?

[wysota]

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]

I just tried it and it worked like a charm No more gui freezing

Thank You!

[jacek]

Another solution is to simply pass Qt::DirectConnection as connection type, but you have create all QObjects in run().