External and Internal Event Processing in Qt

[vijay523201]

Any GUI Framework generally blockwaits on single System call which may multiplex number of soft interfaces. But Qt has two kinds of events viz External events triggered by user through Keyboard & Mouse/Touch screen received by QSocketNotifiers and internal events triggered by QTimers.
Both are being processed sequentially, none of them can be blocking type. Then CPU utilization should be high enough because exec call doesnt yield CPU at all. But it is verified that Qt Applications on Embedded platform is not taking so much of CPU. "select" call used by Qt is not passing NULL for timeout parameter anywhere in source code. Immediately it is looking for any timeouts of Qtimers and is repeating in while loop as long as running.

Then how CPU utilization is fairly Low????

Please explain me where Qt is block-waiting for or How CPU utilization is LOW enough???

[anda_skoa]

I am not sure what you are asking for.

All Qt event dispatcher implementations I had a look at had a single "select" like call, which is the one waiting for any kind of events, usually combined with a timeout to not wait indefinitely.

For example the call in the BlackBerry event dispatcher looks like this


// Wait for event or file to be ready
const int result = bps_get_event(&event, timeoutLeft);

This call blocks until either an event of some sort occured or the timeout is reached.
The thread calling this is suspended by the operating system until either criteria is met.
A suspended thread does not utilize any CPU.

Cheers,
_

[vijay523201]

man pages of select says if timeout is zero, systemcall returns immediately.
nowhere in code it is filled to non zero value. hence must return immediately on linux platform.
if it returns immediately it consumes cpu cycles. but its not happening. where am i understanding wrong.

[sulliwk06]

man pages of select says if timeout is zero, systemcall returns immediately.
nowhere in code it is filled to non zero value. hence must return immediately on linux platform.
if it returns immediately it consumes cpu cycles. but its not happening. where am i understanding wrong.

If you are referring to this:

"timeout is an upper bound on the amount of time elapsed before select()
returns. If both fields of the timeval structure are zero, then
select() returns immediately. (This is useful for polling.) If time‐
out is NULL (no timeout), select() can block indefinitely."

The timeval structure having fields of 0 is not the save thing as using 0 for the timeout in the select call. When you put 0 in the select call, that is the NULL case, (no timeout) which would block indefinitely.

[vijay523201]

in the souece code deliberately timeval struct is filled with zeros. i.e pointer iss not null and waiting time is zero so that select immediately returns. it doesnt block. moreover if it blocks on fds timers timeout will not be honoured.

[anda_skoa]

Luckily, when you have timers, then the wait values are not zero.

Cheers,
_

[vijay523201]

if no timers are there in code, select call will be repeated in a while loop with timeval struct filled with zeros.
when i did the same in a sample linux program, it has taken 100% cpu utilization. but Qt applications are not taking so. thats where i stumbled to understand how much value is filled in timeval struct and where in the code???

[anda_skoa]

if no timers are there in code, select call will be repeated in a while loop with timeval struct filled with zeros.

Only if also the condition "canWait" is false. If it is true, select is called with a null pointer.


i
when i did the same in a sample linux program, it has taken 100% cpu utilization. but Qt applications are not taking so.

That's because the Qt event loop is not doing that.



thats where i stumbled to understand how much value is filled in timeval struct and where in the code???

Most code is on QEventDispatcherUNIX::processEvents().
If there are timers and timers are not excluded by processing flags, then the timeout is calculated in QTimeInfoList::timerWait()

Cheers,
_

[wysota]

nowhere in code it is filled to non zero value.
Of course it is, e.g. in QEventDispatcherUNIX.