From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Broken timers (handle_alarm_signal is never called)? Date: Fri, 25 Jul 2014 17:59:44 +0400 Message-ID: <53D262D0.3020505@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030007030906080909010708" X-Trace: ger.gmane.org 1406296829 25882 80.91.229.3 (25 Jul 2014 14:00:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Jul 2014 14:00:29 +0000 (UTC) Cc: Paul Eggert To: Emacs development discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 25 16:00:20 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XAg2l-0001i5-SP for ged-emacs-devel@m.gmane.org; Fri, 25 Jul 2014 16:00:19 +0200 Original-Received: from localhost ([::1]:55016 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAg2l-00008X-G0 for ged-emacs-devel@m.gmane.org; Fri, 25 Jul 2014 10:00:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAg2b-000062-3i for emacs-devel@gnu.org; Fri, 25 Jul 2014 10:00:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XAg2T-0003pJ-Gv for emacs-devel@gnu.org; Fri, 25 Jul 2014 10:00:09 -0400 Original-Received: from forward1l.mail.yandex.net ([84.201.143.144]:34717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XAg2T-0003oo-93 for emacs-devel@gnu.org; Fri, 25 Jul 2014 10:00:01 -0400 Original-Received: from smtp3h.mail.yandex.net (smtp3h.mail.yandex.net [84.201.186.20]) by forward1l.mail.yandex.net (Yandex) with ESMTP id 587A31521429; Fri, 25 Jul 2014 17:59:58 +0400 (MSK) Original-Received: from smtp3h.mail.yandex.net (localhost [127.0.0.1]) by smtp3h.mail.yandex.net (Yandex) with ESMTP id E67801B44C0D; Fri, 25 Jul 2014 17:59:57 +0400 (MSK) Original-Received: from 146.gprs.mts.ru (146.gprs.mts.ru [213.87.130.146]) by smtp3h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id DK2cyFuTk7-xrMCnZJ0; Fri, 25 Jul 2014 17:59:56 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 1531c780-88c2-4017-9ad8-1662e87263de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1406296797; bh=f4FwOwYh/S8fzePi4y26oxwQLr22cZ3oETUhHP+xetU=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: Content-Type; b=kYLTE6OWSLp/7Wf0H/TBxz+/Sh0sKgWK50pDw7U+8DFfZxGW1gWYYn3N+V6BcFk+K Dhq28pF697+EwhAmFsgunvWqha+G9QC06v+LUDiD+kME2U0o5mOXHRlZpMgtP8s6mT cKdQykf76T53tQXlPCbtFo1R38zdB9UXq4o0fato= Authentication-Results: smtp3h.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 84.201.143.144 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:173139 Archived-At: This is a multi-part message in MIME format. --------------030007030906080909010708 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Can someone explain when handle_alarm_signal is expected to be called? Executing keyboard macro, say, 100000 times, should enter Emacs into "busy" state. Thus hourglass cursor should be displayed, which is done with 1s delay via start_atimer. This means that SIGARLM should be (re)scheduled, and it is. But handle_alarm_signal is never called; instead, timers are processed just after the next input becomes available. So if there is no input, timers will be processed...never? If yes, this looks like a very strange (read: fundamentally broken) timers subsystem. It should be not so hard to observe this scenario under gdb or with attached tracing patch. Dmitry --------------030007030906080909010708 Content-Type: text/x-patch; name="timer-trace.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="timer-trace.patch" === modified file 'src/atimer.c' --- src/atimer.c 2014-05-30 04:12:08 +0000 +++ src/atimer.c 2014-07-25 13:53:31 +0000 @@ -292,7 +292,13 @@ ispec.it_value = atimers->expiration; ispec.it_interval.tv_sec = ispec.it_interval.tv_nsec = 0; if (timer_settime (alarm_timer, 0, &ispec, 0) == 0) - return; + { + fprintf (stderr, "%f: schedule alarm at %ld:%ld\n", + timespectod (current_timespec ()), + atimers->expiration.tv_sec, + atimers->expiration.tv_nsec); + return; + } } #endif @@ -370,6 +376,7 @@ static void handle_alarm_signal (int sig) { + fprintf (stderr, "%f: got %d\n", timespectod (current_timespec ()), sig); pending_signals = 1; } @@ -379,6 +386,7 @@ void do_pending_atimers (void) { + fprintf (stderr, "%f: run timers\n", timespectod (current_timespec ())); if (atimers) { sigset_t oldset; --------------030007030906080909010708--