From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#12471: Avoid some signal-handling races, and simplify. Date: Wed, 19 Sep 2012 12:58:23 -0700 Message-ID: <505A23DF.3090301@cs.ucla.edu> References: <50590626.2070407@cs.ucla.edu> <357A45C4-8E4E-43AA-AF8B-BE2C5B056BA0@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1348084728 2843 80.91.229.3 (19 Sep 2012 19:58:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Sep 2012 19:58:48 +0000 (UTC) Cc: 12471@debbugs.gnu.org, Juanma Barranquero To: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 19 21:58:52 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1TEQQ6-0001M2-VR for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Sep 2012 21:58:51 +0200 Original-Received: from localhost ([::1]:49221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEQQ2-0002Y8-P5 for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Sep 2012 15:58:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38005) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEQPx-0002Xl-OS for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 15:58:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEQPr-00012B-SP for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 15:58:41 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEQPr-000120-Oz for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 15:58:35 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TEQRG-0000iz-0N for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 16:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Sep 2012 20:00:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12471 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 12471-submit@debbugs.gnu.org id=B12471.13480847992756 (code B ref 12471); Wed, 19 Sep 2012 20:00:01 +0000 Original-Received: (at 12471) by debbugs.gnu.org; 19 Sep 2012 19:59:59 +0000 Original-Received: from localhost ([127.0.0.1]:44012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEQRC-0000iP-TP for submit@debbugs.gnu.org; Wed, 19 Sep 2012 15:59:59 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:43176) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEQRA-0000iH-4W for 12471@debbugs.gnu.org; Wed, 19 Sep 2012 15:59:57 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 706CA39E800D; Wed, 19 Sep 2012 12:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0PgY7VX+RxR; Wed, 19 Sep 2012 12:58:28 -0700 (PDT) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id D1A5439E8007; Wed, 19 Sep 2012 12:58:27 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 In-Reply-To: <357A45C4-8E4E-43AA-AF8B-BE2C5B056BA0@swipnet.se> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:64615 Archived-At: On 09/19/2012 09:45 AM, Jan Dj=E4rv wrote:> Hello. > Thread sarted by Gnome/gtk+ plugins can not handle SIGALRM, > so Emacs will terminate. Thanks for looking at the patch. Emacs doesn't terminate for me (Fedora 17, GTK3), but perhaps that's because the problem is specific to non-GNU/Linux platforms. So could you please explain the issue a bit more? Here are some more details to help explain that part of the proposed change. In the Emacs trunk, a thread started by those plugins can already get SIGALRM. If it does, the Emacs-supplied signal handler masks out SIGALRM in the thread, resignals the process with SIGALRM so that some other thread will get the signal next time, and then exits. The thread then resumes doing whatever it was doing, and the main thread eventually gets signaled by SIGALRM. So each Gnome/gtk+ plugin thread might get signaled by SIGALRM, altough it should handle that signal at most once. Under the patch, a thread may handle SIGALRM more than once. Each time it does so, it does something *very* simple (it sets pending_signals to 1). This shouldn't disturb what's happening in the plugin thread, since the plugin thread shouldn't be looking at pending_signals. I've looked at the existing code, and tracked it back to Emacs trunk bzr 58781 dated 2004-12-07, but couldn't find any discussion of what the exact problem was. Back then, alarm timers could run lots of fancy code so it made sense to insist that they run only in the main thread. But nowadays this should no longer be necessary. The patch could be altered so that it retains the signal-mask dance in the Gnome/gtk+ threads, but why bother? Fidding with signal masks in a signal handler is error-prone, because there are race conditions if the interrupted code is itself fiddling with signal masks. It's OK to do this with handlers of fatal signals, because the interrupted code won't be returned to, but for non-fatal signals like SIGALRM it's problematic, and it's better to avoid it if we don't need it. If the above explanation doesn't suffice, could you please give a recipe for reproducing the problem, or point me at a bug report? Thanks.