Rewrite timers

[dmik]

There is a known limitation in PM on the global number of timers that can coexist simultaneously across all processes. On my system, this number is just 28 timers but it probably depends on other system resources and changes from system to system.

When the number of timers has reached its maximum, applications that don't properly handle timer creation errors may hang or crash or just refuse to work if they do handle these errors in a a nice way.

Qt may use quite a lot of timers (several of them are constantly used during the whole application lifetime for things like the blinking cursor and tool-tips). This affects existing applications as described above. See ​http://svn.netlabs.org/qtapps/ticket/8 for more details about such applications.

The possible way to fix this limitation is to implement our own timer service in Qt which will be independent from system PM timers.

[komh]

Hi dmik,

any chance this enhancement gets done in the near future? I actually stopped using Psi regularily because of the timer problem. (Just use it once in a while when necessary, but close it again asap to prevent my system from getting unstable.) If there wasn't the timer limitation Psi would still be best IM available for OS/2 right now!

Regards Axel

[dmik]

Axel, thank you for constantly kicking me :) The independent timers are half-way done. You can expect it to be finished soon.

[komh]

dmik,

I'm very looking forward to testing it soon then...

Thanks!

[komh]

Another month has gone by.... maybe a good moment to ask for the current status ;-).

Axel

[dmik]

New Qt timers using one auxiliary thread and up to two DOS timers are implemented in r176. The new timer implementation doesn't have any particular limit on the total number of timers, but I limited it myself to 1024 timers per Qt process for performance reasons (see below).

The old broken PM timer based code can be restored using the QT_PM_NO_DOSTIMERS define (added it just to save the old code for reference).

Below are the results of running a simple testcase with timer driven counters on my machine. The counter increases each time the timer fires an event. Even timers are 1 second, odd ones are 0.5 second. Percentage numbers are the CPU load when the testcase window is in foreground (e.g. running counters are visible) and when it's minimized, correspondingly. The idle CPU load is 0.5% in all tests.

   Number of          DOS          PM
   timers (visible)   timers, %%   timers, %%
   ----------------   ----------   ----------
1. 32 (32)             1.4 / 0.9   1.2 / 0.7
2. 500 (312)          20.4 / 5.4   (impossible)
3. 1000 (312)         96.0 / 10.3  (impossible)

The slight difference in 1. may be caused by the different timer thread priority though I don't think that this difference is really significant. High load on big amounts of counters is most likely a PM performance issue (there are three PM windows per each counter and almost all screen is covered by constantly repainting labels.

BTW, I also noticed that PM timers may skip intervals. E.g. if there are two 1-second timer based counters running in different applications, one of them may lag behind the second one at least by one. It may be a Qt bug though; I didn't investigate.

[dmik]

I've compiled a test build of Psi 0.10.2 as a real life testcase. Look here ​http://svn.netlabs.org/qtapps/ticket/8 for more info.