[Interest] QEventDispatcherGlib: timers don't timeout due to higher priority of socket notifier event dispatching.

Danny Smit danny.smit.0 at gmail.com
Thu Sep 17 15:38:04 CEST 2015


I'm running into an issue where it seems that Qt timers are not timing
out anymore when the application has a lot of other events (say
continues stream of events) to process. For instance, when the
application receives lots of small pieces of data on (TCP) sockets,
resulting in a lot of events to be dispatched.


This applies to Qt on linux. It is a situation difficult to reproduce,
but is more or less reproducible by creating a "receiver" application
using QSocketNotifier directly or using a QTcpSocket in buffered state
or buffer size of 1. Next create a sender application that produces a
continues stream of small pieces of data. I can provide a reproducible
case if needed.


But first, this seems to be related to the fact that
QEventDispatcherGlib implements two timer sources for the glib event
loop processing (see its constructor):


1. Event dispatching with default priority, which is prioritized
equally to other events, like socket notifier events.

2. Event dispatching with 'idle' priority, which is a lower priority
than the default priority. The dispatching of these events only occurs
when the application is 'idle'. ( see the use of
g_source_set_priority(<source>, G_PRIORITY_DEFAULT_IDLE) )


The second case seems to be applicable to all timers in general, when
the application's event loop is running. This means that as long as
there are other events than timer events to be dispatched, The timers
do not run out.


What is interesting is that this behavior does not occur when
switching to QEventDispatcherUnix (using the environment variable
QT_NO_GLIB=1). With the unix event dispatcher, the timers keep running
out as the event dispatching seem to be prioritized equally to other
type of events. Even without much of a delay, although the rate of
incoming data pieces is relatively high.


The behavior of the UNIX event dispatcher feels more reasonable,
because it ensures that all timer events will be triggered and get
there processing time without unnecessary delay.


However it looks like the 'idle' priority was implemented for a
reason. But considering the side effects described above, it doesn't
seem to work as expected.


Can someone advise whether this is the behavior as intended or whether
this points to an issue in Qt?

Regards,
Danny Smit



More information about the Interest mailing list