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

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: stefan <at> marxist.se, 19776 <at> debbugs.gnu.org,
 Stefan Monnier <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 16:05:01 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> In my testing, handle_alarm_signal (which should set pending_signals) is
> never called. 

I should have read the code more closely:

void
init_atimer (void)
{
#ifdef HAVE_ITIMERSPEC
# ifdef HAVE_TIMERFD
  /* Until this feature is considered stable, you can ask to not use it.  */
  timerfd = (egetenv ("EMACS_IGNORE_TIMERFD") || have_buggy_timerfd () ? -1 :
	     timerfd_create (CLOCK_REALTIME, TFD_NONBLOCK | TFD_CLOEXEC));
# endif
  if (timerfd < 0)
    {
      struct sigevent sigev;
      sigev.sigev_notify = SIGEV_SIGNAL;

So if we have timerfd, the alarm stuff is not set up.

And...  uhm...

EMACS_IGNORE_TIMERFD=t ./src/emacs 

doesn't disable it, either?  That egetenv call returns NULL even if I
start Emacs like that?  Odd.  Anyway, if I forcibly disable timerfd,
then the atimers work like they're supposed to, and the correct code
paths are triggered at the time they're supposed to.

So the timerfd stuff doesn't actually work.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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