bug#19776: 25.0.50; HTML rendering is very slow

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefan@marxist.se,  rms@gnu.org,
>   19776@debbugs.gnu.org
> Date: Mon, 25 Oct 2021 00:28:12 +0200
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Basically all loops should call `maybe_quit`, so the issue is probably
> > not that `maybe_quit` is not called often enough, but that for some
> > reason we don't set the vars that it checks or something like that.
> 
> I've been trying to follow the logic in how the atimer stuff is supposed
> to work.  It registers a special timer fd that sets a timeout, and it's
> supposed to be called back in timerfd_callback.  And that happens if I'm
> (for instance) idling in a `sleep-for'.
> 
> When Emacs is busy looping, we never get a callback -- presumably
> because we're not reading any file descriptors in that case?  But...
> was the idea that this would work in a busy Emacs?  I mean, events from
> the keyboard/mouse are able to poke Emacs in a way that it realises that
> it has a pending event to handle, but not the timerfd?

Input events work via SIGIO on X, and SIGIO sets pending_signals, and
then we check the atimers.

I guess this means timerfd is only good for when Emacs is calling
thread_select, i.e. either it's idling or waiting for process output.
So timerfd, if available, should be used together with interval
timers, so that we get SIGALRM when we aren't idle, I guess.  Not
either timerfd or interval timers, but both.