all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: 12471@debbugs.gnu.org, Juanma Barranquero <lekktu@gmail.com>
Subject: bug#12471: Avoid some signal-handling races, and simplify.
Date: Thu, 20 Sep 2012 08:27:09 +0200	[thread overview]
Message-ID: <93EF5307-82D9-47A2-ADB2-2C103CD279DA@swipnet.se> (raw)
In-Reply-To: <505A23DF.3090301@cs.ucla.edu>


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	other threads:[~2012-09-20  6:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-18 23:39 bug#12471: Avoid some signal-handling races, and simplify Paul Eggert
2012-09-19 16:18 ` Eli Zaretskii
2012-09-20  6:07   ` Paul Eggert
2012-09-20 17:44     ` Eli Zaretskii
2012-09-21  7:42       ` Paul Eggert
2012-09-21  8:31         ` Eli Zaretskii
2012-09-21 17:26           ` Paul Eggert
2012-09-21 17:38             ` Eli Zaretskii
2012-09-21 18:13               ` Paul Eggert
2012-09-21 18:27                 ` Eli Zaretskii
2012-09-21 19:59                   ` Paul Eggert
2012-09-22  8:02                     ` Eli Zaretskii
2012-09-22  8:47                       ` Paul Eggert
2012-09-22  9:10                         ` Eli Zaretskii
2012-09-22  9:40                           ` Paul Eggert
2012-09-22 10:07                             ` Eli Zaretskii
2012-09-22 10:55                               ` Paul Eggert
2012-09-22 11:16                                 ` Eli Zaretskii
2012-09-22 20:28                               ` Stefan Monnier
2012-09-22 21:55                                 ` Paul Eggert
2012-09-23  3:55                                   ` Eli Zaretskii
2012-09-23  3:52                                 ` Eli Zaretskii
2012-09-19 16:45 ` Jan Djärv
2012-09-19 19:58   ` Paul Eggert
2012-09-20  6:27     ` Jan Djärv [this message]
2012-09-19 21:36 ` Andy Moreton
2012-09-23  9:36 ` bug#12471: installed into trunk Paul Eggert
2012-09-23 15:22   ` Andy Moreton
2012-09-23 16:23     ` Andy Moreton
2012-09-23 17:37       ` Juanma Barranquero
2012-09-23 17:37     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=93EF5307-82D9-47A2-ADB2-2C103CD279DA@swipnet.se \
    --to=jan.h.d@swipnet.se \
    --cc=12471@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=lekktu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.