[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.
- bug#12471: Avoid some signal-handling races, and simplify., (continued)
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Stefan Monnier, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Paul Eggert, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
- bug#12471: Avoid some signal-handling races, and simplify., Eli Zaretskii, 2012/09/22
bug#12471: Avoid some signal-handling races, and simplify., Jan Djärv, 2012/09/19
bug#12471: Avoid some signal-handling races, and simplify., Andy Moreton, 2012/09/19
bug#12471: installed into trunk, Paul Eggert, 2012/09/23