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

Previous Next

Full log

Message #166 received at 19776 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 19776 <at> debbugs.gnu.org, stefan <at> marxist.se, monnier <at> iro.umontreal.ca,
 rms <at> gnu.org
Subject: Re: bug#19776: 25.0.50; HTML rendering is very slow
Date: Mon, 25 Oct 2021 19:53:47 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: monnier <at> iro.umontreal.ca,  stefan <at> marxist.se,  rms <at> gnu.org,
>   19776 <at> debbugs.gnu.org
> Date: Mon, 25 Oct 2021 18:19:01 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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.
> 
> But does timerfd give us anything extra, then?  If we only use interval
> timers, things seems to work fine.  So I wonder what the purpose of
> introducing the timerfd stuff was.  Greater efficiency?  

Not sure.  Maybe more reliability?  Signals can be lost or blocked.  I
hope Dmitry will be able to answer that.

Previous Next

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