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

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 12471 <at> debbugs.gnu.org, Juanma Barranquero <lekktu <at> gmail.com>
Subject: bug#12471: Avoid some signal-handling races, and simplify.
Date: Wed, 19 Sep 2012 12:58:23 -0700

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?

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.

Previous Next

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