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

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

bug#12471: Avoid some signal-handling races, and simplify.


From: Jan Djärv
Subject: 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@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.







reply via email to

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