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.