kernel32/tests: Verify the stability of CreateTimerQueue.

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

>sometimes one DeleteTimerQueueTimer(INVALID_HANDLE_VALUE)
>fails (presumably with IO_PENDING) because a callback was executing concurrently.
This random failure rose an alarm. I looked at it further and found out that
the current testsuite is not complete enough to demonstrate that given
INVALID_HANDLE_VALUE, DLQT always succeeds without IO_PENDING.
I'll rework my "Do not execute callbacks past DeleteTimer" patch and add a test.

Alexandre Julliard wrote:
>> I've been using
>> if (winetest_debug > 0)
>> partly because the trace output in a Gnome-terminal slows down wine such that the tests fail
>> -- redirect output to a file and the problem goes away (testbot does this) --
>> and partly because make -j can cause a high system load, causing an inability to
>> maintain the average rate (make test uses runtest -q, i.e. winetest_debug==0).
>This is not a good idea. Tests have to be run by make test. Running
>tests with make -j is not supported anyway.

What do you suggest?
a) remove if(winetest...) and always execute the average test
 - Live with occasional failures when the Linux scheduler decides so.
   (This is not unlike audio glitches when sometimes, Linux wakes up a thread after 100ms only).
 - Live with occasional failures on test.winehq from the testbot VM's when they are too busy.
   I've yet to see a failure from a real MS machine.

b) Always use if (winetest_debug > 1) such that neither normal make nor test.winehq.org
 execute the tests. You'll need runtest -v or WINETEST_INTERACTIVE=2
 Somehow that would be a pity.

c) Generally use (winetest_debug > 1) but always execute the average check with the 117ms
  period tests which are perhaps the least prone to be disturbed by other jobs.

d) Generally perform the average check except for the most problematic ones which will only
 be executed when (winetest_debug >0) or >1
  Except "most problematic" is ill-defined.  Any tests can be hit by a 100ms scheduler delay.

e) ...?

Thank you,
 Jörg Höhle