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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest