GNU bug report logs - #12471
Avoid some signal-handling races, and simplify.

Previous Next

Full log

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12471 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>
Subject: Re: bug#12471: Avoid some signal-handling races, and simplify.
Date: Thu, 20 Sep 2012 08:27:09 +0200

19 sep 2012 kl. 21:58 skrev Paul Eggert <eggert <at> cs.ucla.edu>:

> On 09/19/2012 09:45 AM, Jan Djärv 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?

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).

> 
> 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.

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.

Previous Next

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