From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Newsgroups: gmane.emacs.bugs Subject: bug#12471: Avoid some signal-handling races, and simplify. Date: Thu, 20 Sep 2012 08:27:09 +0200 Message-ID: <93EF5307-82D9-47A2-ADB2-2C103CD279DA@swipnet.se> References: <50590626.2070407@cs.ucla.edu> <357A45C4-8E4E-43AA-AF8B-BE2C5B056BA0@swipnet.se> <505A23DF.3090301@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1348122458 12418 80.91.229.3 (20 Sep 2012 06:27:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Sep 2012 06:27:38 +0000 (UTC) Cc: 12471@debbugs.gnu.org, Juanma Barranquero To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 20 08:27:41 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 1TEaEf-0003AD-D3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Sep 2012 08:27:41 +0200 Original-Received: from localhost ([::1]:52814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEaEb-0004y7-0B for geb-bug-gnu-emacs@m.gmane.org; Thu, 20 Sep 2012 02:27:37 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEaEY-0004y0-6a for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 02:27:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEaEX-0007yz-1u for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 02:27:34 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEaEW-0007yZ-T4 for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 02:27:32 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TEaFx-0007bp-Gd for bug-gnu-emacs@gnu.org; Thu, 20 Sep 2012 02:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jan =?UTF-8?Q?Dj=C3=A4rv?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 20 Sep 2012 06:29: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.134812252129223 (code B ref 12471); Thu, 20 Sep 2012 06:29:01 +0000 Original-Received: (at 12471) by debbugs.gnu.org; 20 Sep 2012 06:28:41 +0000 Original-Received: from localhost ([127.0.0.1]:44447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEaFc-0007bH-EE for submit@debbugs.gnu.org; Thu, 20 Sep 2012 02:28:40 -0400 Original-Received: from mailout.attendit.se ([83.140.103.4]:58801) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEaFZ-0007bA-Ua for 12471@debbugs.gnu.org; Thu, 20 Sep 2012 02:28:39 -0400 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.attendit.se (Postfix) with ESMTP id 03ED150147 for <12471@debbugs.gnu.org>; Thu, 20 Sep 2012 08:21:00 +0200 (CEST) Original-Received: (qmail 5579 invoked by uid 89); 20 Sep 2012 06:26:40 -0000 Original-Received: from h-46-59-42-18.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.18) by mail01.melmac.se with ESMTPA; 20 Sep 2012 06:26:40 -0000 Original-Received: from [172.20.199.13] (zeplin [172.20.199.13]) by coolsville.localdomain (Postfix) with ESMTPSA id 4310E7FA05E; Thu, 20 Sep 2012 08:27:07 +0200 (CEST) In-Reply-To: <505A23DF.3090301@cs.ucla.edu> X-Mailer: Apple Mail (2.1486) 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:64634 Archived-At: 19 sep 2012 kl. 21:58 skrev Paul Eggert : > On 09/19/2012 09:45 AM, Jan Dj=E4rv wrote:> Hello. >=20 >> Thread sarted by Gnome/gtk+ plugins can not handle SIGALRM, >> so Emacs will terminate. >=20 > 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? I think this is the starting point: http://lists.gnu.org/archive/html/emacs-devel/2005-02/msg01142.html I found some other relevant threads that show how the code evolved: = http://lists.gnu.org/archive/html/emacs-pretest-bug/2006-08/msg00005.html http://lists.gnu.org/archive/html/emacs-devel/2006-08/msg00633.html http://lists.gnu.org/archive/html/bug-gnu-emacs/2007-06/msg00051.html Basically other threads are created by some libraries (DBus, Gtk+ file = dialog plugins). It is generally undefined to which thread a signal get delivered, and = some operations are only safe to do in the main thread (i.e. malloc). >=20 > 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. >=20 > 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. Ok, I missed that part, if we only do simple stuff, it will be ok. But = previously a lot of stuff happend in the signal handler. If we can = remove those cases, all is well. Jan D.