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
> 
> 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?

I didn't yet take a good look at the code, so I may not make sense,
but: if the problem with getting Emacs to check atimers is that it
needs an input event, then does it help to define a one-time timer
in addition to arranging the atimer?  When we have an active timer, we
artificially reduce the timeout for pselect so that it expires before
the expected timer -- maybe that is all that's needed, to cause the
input loop crank one more revolution?