RFC re winmm/time.c

[Eric Pouech]

Jeremy White a écrit :
> Hi Folks,
> 
> I ran into a problem with PowerPoint and winmm timer events,
> that has led me to radically alter this file.
> 
> However, I'd appreciate a gut check from anyone more
> experienced with it than I.
> 
> The fundamental problem is that Powerpoint does a
> timeBeginPeriod(1), trying to set timer resolution
> to 1 ms; we steadfastly discard that, and continue
> generating time updates and events on a roughly
> 10 ms interval, this can, in rare situations,
> lead to some awkward delays.
> 
> Some investigation with a test program shows that most Windows systems 
> start with a default resolution of 1 ms.
> This test program is attached; the 'average' reported
> at the top is the default resolution.  Further, Windows seem to
> steadfastly ignore any timeBeginPeriod(x)
> where x > the current period.  I surveyed about 6 systems;
> a mix on Win98/Win2k and Win XP.  All but one rogue
> Win 2K system had a 1 ms timer interval (the rogue system
> had a 10 ms interval; why, I do not know).  The MSDN
> pages suggest (but don't state clearly) that this
> is the expected behavior.
mm timers have been created to give better resolution than the old 
ticker from DOS (55ms, 18.2 ticks per second). But this requires 
specific hardware to do so, hence the various results you get. I would 
assume that on recent boxes you get 1ms as lowest resolution.

> This behavior essentially means that on most Windows systems
> the timer resolution of winmm is 1ms and can not be changed.
> 
> So, question #1:  anyone object if I fix the timer resolution at 1 ms?
> 
> Next, if I make this change, it makes the code in time.c,
> which is fairly awkward imho, even less efficient.
> We'll basically be scanning a loop every ms for no
> particularly good reason.
> 
> I couldn't stomach this, so I rewrote it.
> Question #2: anyone object to my change?  I have tested
> it with my attached test program, and I appear to have
> gotten it right, but...
the current code had been written (hmmm) with the assumption that 
GetTickCount() could have a resolution of 55ms, hence you couldn't rely 
on it and had to do the job yourself for a better resolution.

Wine provides 1ms resolution in GetTickCount, ReactOs does also (through 
  a quicly browsing of the code) (and the number of cases where winmm 
will be run on Windows), so the basic proposition sounds fine.

 From an implementation point of view, there's something wrong with it. 
The time returned from TIME_MMSysTimeCallback (time to wait for next 
timer to elapse) only takes into account the timers which existed when 
the function is entered, not the ones which could have been created or 
deleted while processing the callbacks.

Another point, with your proposal, we could use the fact that the global 
time no longer needs to be maintained, hence the worker thread can be 
destroyed when no more timers exist.

A+