From: Ken Brown <kbrown@cornell.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 51734-done@debbugs.gnu.org, yamaoka@jpl.org
Subject: bug#51734: 29.0.50; got slow
Date: Fri, 12 Nov 2021 15:06:33 -0500 [thread overview]
Message-ID: <1c5199f3-45ce-c98e-aecd-9ce76b2f7c9c@cornell.edu> (raw)
In-Reply-To: <83wnldxjiv.fsf@gnu.org>
On 11/12/2021 2:26 PM, Eli Zaretskii wrote:
>> Date: Fri, 12 Nov 2021 13:22:28 -0500
>> Cc: yamaoka@jpl.org, 51734@debbugs.gnu.org
>> From: Ken Brown <kbrown@cornell.edu>
>>
>> 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
next prev parent reply other threads:[~2021-11-12 20:06 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-10 0:36 bug#51734: 29.0.50; got slow Katsumi Yamaoka
2021-11-10 12:38 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-11-10 14:08 ` Eli Zaretskii
2021-11-10 12:53 ` Eli Zaretskii
2021-11-11 2:43 ` Katsumi Yamaoka
2021-11-11 8:09 ` Eli Zaretskii
2021-11-11 12:02 ` Katsumi Yamaoka
2021-11-11 14:15 ` Eli Zaretskii
2021-11-11 18:11 ` Ken Brown
2021-11-11 18:33 ` Ken Brown
2021-11-11 18:42 ` Eli Zaretskii
2021-11-11 19:28 ` Ken Brown
2021-11-11 20:17 ` Ken Brown
2021-11-11 20:20 ` Eli Zaretskii
2021-11-11 20:30 ` Ken Brown
2021-11-11 20:36 ` Eli Zaretskii
2021-11-11 23:45 ` Katsumi Yamaoka
2021-11-12 18:22 ` Ken Brown
2021-11-12 19:26 ` Eli Zaretskii
2021-11-12 20:06 ` Ken Brown [this message]
2021-11-14 1:13 ` Lars Ingebrigtsen
2021-11-14 15:42 ` Ken Brown
2021-11-14 17:58 ` Lars Ingebrigtsen
2021-11-14 19:11 ` Ken Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1c5199f3-45ce-c98e-aecd-9ce76b2f7c9c@cornell.edu \
--to=kbrown@cornell.edu \
--cc=51734-done@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=yamaoka@jpl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.