wine CPU usage and CreateWaitableTimer

[Sebastian Lackner]

On 07.07.2015 21:49, andrea wrote:
> On 07/06/15 19:08, Sebastian Lackner wrote:
>> Hello andrea,
>>
>> good catch, its actually a bug in SystemClockAdviseThread. A patch like:
>>
>> --- snip ---
>> diff --git a/dlls/quartz/systemclock.c b/dlls/quartz/systemclock.c
>> index 043299b..ac41a49 100644
>> --- a/dlls/quartz/systemclock.c
>> +++ b/dlls/quartz/systemclock.c
>> @@ -127,6 +127,7 @@ static DWORD WINAPI SystemClockAdviseThread(LPVOID lpParam) {
>>         it = nextit;
>>       }
>>       if (NULL != it) timeOut = (DWORD) ((it->rtBaseTime + it->rtIntervalTime) - curTime) / (REFERENCE_TIME)10000;
>> +    else timeOut = INFINITE;
>>
>>       /** Now Periodics Advice: semi sorted list (sort cannot be used) */
>>       for (it = This->pPeriodicAdvise; NULL != it; it = it->next) {
>> --- snip ---
>>
>> Seems to be sufficient to fix it. I will review the code for other errors one more time,
>> and then submit the patch.
>>
>> Regarding your second question, the best timer (when using for events) is
>> CreateWaitableTimer in my opinion. All other timers need separate threads, and need an
>> additional wineserver call for event handling.
>>
>> Regards,
>> Sebastian
>>
> 
> Hi,
> 
> I just wanted to check with you, if you have an idea why this patch works well for long-ish periods (>3 ms), while for 1 or 2 ms (according to the pc/situation) produces actual waits that can be much longer than requested.
> 
> on a machine I got 8ms average realised vs 1ms period requested.
> 
> thanks
> 
> 

Hello andrea,

I just saw by pure accident that you already wrote a couple of mails before this one, they all landed in my spam folder somehow (?!).

Regarding your question:

The whole implementation of the clock is not really very efficient (separate thread, message loops, events, ...).
Before the patch, as soon as timeOut reached a value of zero (or just a very small value), the thread was busy-looping
all the time, no matter if timers were queued or not. After the patch, the thread sleeps in the meantime, as expected.
The patch itself was definitely correct, but the code was written over 10 years ago, there might be lot of opportunities
to do things more efficient.

Is there any app which explicitly uses such a small delay (and doesn't work well when there is too much overhead)? If
yes, please open a new bug report and add me as CC. You can also add your code as testcase there.

Regards,
Sebastian