Subject: Re: bug#51734: 29.0.50; got slow
From: Ken Brown <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Fri, 12 Nov 2021 15:06:33 -0500
List-Id: <debbugs-submit.debbugs.gnu.org>

On 11/12/2021 2:26 PM, Eli Zaretskii wrote:
>> Date: Fri, 12 Nov 2021 13:22:28 -0500
>> Cc: [email-masked], [email-masked]
>> From: Ken Brown <[email-masked]>
>>
>> The only thing I can think of is that Cygwin is probably the only system that
>> has timerfd and that also has to use timers to poll for input.  (The others all
>> use SIGIO, if I'm not mistaken.)  By using two different kinds of timers
>> simultaneously, we're getting timers expiring twice as often and not at regular
>> intervals.  Could this account for the slowdown?
> 
> At what frequency does the other timer tick, the one used to poll for
> input?

They're both used to poll for input, and both at the same frequency (I think 
every second).  For systems without SIGIO, keyboard.c:start_polling creates an 
atimer "poll_timer" via a call to start_atimer.  The latter calls set_alarm, 
which now (after commit 858868e3) calls both timerfd_settime and timer_settime. 
  So we have both a timerfd and a POSIX timer, both serving the same purpose AFAICT.

When I said "not at regular intervals" above, I meant that there will sometimes 
be delays before Emacs notices a timer expiring, so the two timers will get out 
of phase with another.

I hope this makes some sense.  I find keyboard.c and the whole alarm setup 
confusing, so I could easily have gotten some things wrong.

>> In any case, I think I should go ahead and install the patch to make the master
>> branch usable again on Cygwin.
> 
> Feel free.

Done, and I'm closing the bug.

Ken