Re: [AD] pthread timer and event processing

["Eric Botcazou" <ebotcazou@xxxxxxxxxx>]

> Can we clarify a few points? I'm not too clear on what effects this will
> have:

I'm here for that ;-)

> >- revert to the previous semantics for install_in_ex() when the timer is
> >   already installed and make it explicit in the docs: this will fix the
> >   MIDI problem on all platforms,
>
> Does this leave us with any unsatisfactory behaviour?

Not really if we make the docs clear enough.

I modified install_int() because of the following thing: suppose you
installed a 1 second timer, now you reinstall it (without removing it
before) with a 10 ms period.
If the second install_int() call is performed in the middle of the first
period (500 ms after a tick), then the next tick is correctly scheduled 10
ms ahead of the present time.
But when the tick is triggered, the code in src/timer.c:_handle_timer_tick()
calculates that the last tick is 510 ms old, which is equivalent to 51
periods of 10 ms, hence calls the timer proc 51 times to compensate for what
it thinks are 50 missed ticks.

That kind of retroactive speed adjusting ensures there is no gap between the
different periods and the MIDI player seems to be relying on it. It is far
simpler to revert to it than to try to modify the MIDI code.

Now you may not want to use this feature when changing the timer speed: the
solution is simply to stop the timer by calling remove_int() then to
reinstall it. This works flawlessly with all drivers except the Windows MT
driver under certain circumstances (in the original keyboard autorepeat
handling code for example).

> >- revert to the previous keyboard autorepeat handling code,
>
> Again, will this have any effect on the end user?

Absolutely none.
The code will simply revert to the remove/reinstall scheme for the
autorepeat timer.

--
Eric Botcazou
ebotcazou@xxxxxxxxxx