GNU bug report logs - #19776
25.0.50; HTML rendering is very slow

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 19776 <at> debbugs.gnu.org, stefan <at> marxist.se, monnier <at> iro.umontreal.ca, rms <at> gnu.org
Subject: bug#19776: 25.0.50; HTML rendering is very slow
Date: Mon, 25 Oct 2021 17:00:35 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  stefan <at> marxist.se,  rms <at> gnu.org,
>   19776 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.