emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#15561: closed (Timer can miss its SIGALRM)


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#15561: closed (Timer can miss its SIGALRM)
Date: Tue, 25 Mar 2014 14:46:02 +0000

Your message dated Tue, 25 Mar 2014 07:45:01 -0700
with message-id <address@hidden>
and subject line Re: bug#15561: periodic timer stops running
has caused the debbugs.gnu.org bug report #15561,
regarding Timer can miss its SIGALRM
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
15561: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15561
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Timer can miss its SIGALRM Date: Tue, 8 Oct 2013 10:20:47 -0400
Looking over the timer code, the do_pending_atimers function does:

      block_atimers ();
      run_timers ();
      unblock_atimers ();

The last line of run_timers is:

  set_alarm ();

But what happens if the next timer happens to be soon, and Emacs
receives SIGALRM inbetween set_alarm and unblock_timers?

What is the purpose of sigmasking SIGALRM anyway? If it means to block
SIGALRM during timers, that doesn't always happen because timers run
within timers. The end of an inner timer would unblock SIGALRM and
the outer timer would finish with the sigmask unblocked.


--- End Message ---
--- Begin Message --- Subject: Re: bug#15561: periodic timer stops running Date: Tue, 25 Mar 2014 07:45:01 -0700 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
Barry OReilly wrote:
I think applying Paul Eggert's patch is all that's left to this bug
report then. Since it solves a theoretical flaw rather than one
witnessed, maybe it's appropriate for trunk?

Sounds good; done as trunk bzr 116018.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]