bug#9216: Signal handling and pthreads

bug#9216: Signal handling and pthreads

[Stefan Monnier]

In syssignal.h we have:

   #if defined (HAVE_GTK_AND_PTHREAD) || defined (HAVE_NS)
   #include <pthread.h>
   /* If defined, asynchronous signals delivered to a non-main thread are
      forwarded to the main thread.  */
   #define FORWARD_SIGNAL_TO_MAIN_THREAD
   #endif

But that is not right: the test should bot be for HAVE_NS and HAVE_GTK,
but just for using pthreads.  There are more ways to get
pthreads involved.  E.g. I just got the following assertion failure:

   #0  abort () at emacs.c:381
   #1  0x08373ba2 in die (
       msg=0x860ae8c "assertion failed: handling_signal == 0", 
       file=0x8603867 "keyboard.c", line=7183) at alloc.c:6232
   #2  0x082be485 in input_available_signal (signo=29) at keyboard.c:7183
   #3  <signal handler called>
   #4  0xb7fe2424 in __kernel_vsyscall ()
   #5  0xb73b5f86 in poll () from /lib/i386-linux-gnu/i686/cmov/libc.so.6
   #6  0xb7890f5b in g_poll () from /lib/libglib-2.0.so.0
   #7  0xb788096f in ?? () from /lib/libglib-2.0.so.0
   #8  0xb78810f3 in g_main_loop_run () from /lib/libglib-2.0.so.0
   #9  0xb64396f4 in ?? () from /usr/lib/gio/modules/libdconfsettings.so
   #10 0xb78a9b6f in ?? () from /lib/libglib-2.0.so.0
   #11 0xb77dec39 in start_thread ()
      from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0
   #12 0xb73c396e in clone () from /lib/i386-linux-gnu/i686/cmov/libc.so.6

Where the "handling_signal == 0" check is one I added to
input_available_signal right after the SIGNAL_THREAD_CHECK.  This is
with a Lucid build: pthreads gets involved because of
libdconfsettings, apparently.

IOW we should also set FORWARD_SIGNAL_TO_MAIN_THREAD when using
libdconfsettings (and maybe some more).  Tho a better fix might be to
better set up our signal handlers so we don't need this
SIGNAL_THREAD_CHECK hack which seems unreliable (it drops signals on
the floor when delivered to the wrong thread, which would seem to mean
the main thread may fail to be told about pending input to be processed).


        Stefan




In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2011-08-01 on ceviche
Windowing system distributor `The X.Org Foundation', version 11.0.11002000
configured using `configure  'CFLAGS=-Wall -Wno-pointer-sign -DUSE_LISP_UNION_TYPE -DSYNC_INPUT -DENABLE_CHECKING -DXASSERTS -DFONTSET_DEBUG -g -O1 -I/usr/include/GNUstep' '--enable-maintainer-mode' '--with-x-toolkit=lucid''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_CH.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: InactiveMinibuffer

Minor modes in effect:
  electric-pair-mode: t
  electric-indent-mode: t
  url-handler-mode: t
  global-reveal-mode: t
  reveal-mode: t
  auto-insert-mode: t
  savehist-mode: t
  minibuffer-electric-default-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<switch-frame> <select-window> <select-window> C-x 
5 0 M-x r e - e m - b u <tab> <return>

Recent messages:
Loading ~/src/elisp/bbdb/lisp/bbdb-autoloads...done
Loading /home/monnier/src/elisp/ProofGeneral/generic/proof-site.el (source)...done
Warning: set-coding-priority is obsolete!
Warning: interactive-p is obsolete!
Loading /home/monnier/src/elisp/sml-mode/sml-mode-startup.el (source)...done
Loading /home/monnier/etc/emacs/X11.el (source)...done
Loading /home/monnier/etc/emacs/custom.el (source)...done
Ispell-kill: nil american
Starting new Ispell process [american] ...
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message format-spec rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev mail-utils gmm-utils mailheader emacsbug server noutline
outline easy-mmode flyspell ispell eldoc checkdoc regexp-opt thingatpt
help-mode view prog-mode load-dir electric url-handlers url-parse
auth-source warnings eieio byte-opt bytecomp byte-compile cconv macroexp
assoc gnus-util password-cache url-vars mm-util mail-prsvr reveal
autoinsert uniquify advice help-fns advice-preload time-date savehist
minibuf-eldef disp-table cl cl-loaddefs all-autoloads company-autoloads
debbugs-autoloads epoch-view-autoloads js2-mode-autoloads
load-dir-autoloads markchars-autoloads minimap-autoloads muse-autoloads
info easymenu rainbow-mode-autoloads register-list-autoloads
sisu-mode-autoloads uni-confusables-autoloads windresize-autoloads
package tabulated-list proof-site proof-autoloads pg-vars bbdb-autoloads
agda2 tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image fringe lisp-mode register page newcomment
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)

bug#9216: Signal handling and pthreads

[Jan Djärv]

Hi.


Stefan Monnier skrev 2011-08-01 19:44:
> In syssignal.h we have:
>
>     #if defined (HAVE_GTK_AND_PTHREAD) || defined (HAVE_NS)
>     #include<pthread.h>
>     /* If defined, asynchronous signals delivered to a non-main thread are
>        forwarded to the main thread.  */
>     #define FORWARD_SIGNAL_TO_MAIN_THREAD
>     #endif
>
> But that is not right: the test should bot be for HAVE_NS and HAVE_GTK,
> but just for using pthreads.  There are more ways to get
> pthreads involved.

At first, only GTK could start different threads in Emacs.  But this has 
changed now, with Dbus and others.

The usage of threads within libraries is an internal matter, so I think Emacs 
should be prepared for threads always when <pthread.h> is available.

This will become more important if runtime linking of libraries introduces 
threads in Emacs.  So Emacs should use pthread always where available, just to 
be prepared.

>
> IOW we should also set FORWARD_SIGNAL_TO_MAIN_THREAD when using
> libdconfsettings (and maybe some more).  Tho a better fix might be to
> better set up our signal handlers so we don't need this
> SIGNAL_THREAD_CHECK hack which seems unreliable (it drops signals on
> the floor when delivered to the wrong thread, which would seem to mean
> the main thread may fail to be told about pending input to be processed).
>

Are you thinking of sigwait?  Other than sigwait, there is no way to "set up 
our signal handlers so we don't need this", where this == SIGNAL_THREAD_CHECK.

SIGNAL_THREAD_CHECK is not unreliable.  It does not drop signals delivered to 
the wrong thread, it forwards them to the main thread.

	Jan D.

bug#9216: Signal handling and pthreads

[Stefan Monnier]

> The usage of threads within libraries is an internal matter, so I think
> Emacs should be prepared for threads always when <pthread.h> is available.

That's also my impression.

> Are you thinking of sigwait?  Other than sigwait, there is no way to "set up
> our signal handlers so we don't need this", where this ==
> SIGNAL_THREAD_CHECK.

I was afraid so.

> SIGNAL_THREAD_CHECK is not unreliable.  It does not drop signals delivered
> to the wrong thread, it forwards them to the main thread.

Indeed, I had misread the code.


        Stefan

bug#9216: Signal handling and pthreads

[Jan Djärv]

Hello.

I've renamed HAVE_GTK_AND_PTHREAD to HAVE_PTHREAD and check for pthread 
regardless of Gtk+.

	Jan D.


Stefan Monnier skrev 2011-08-02 15:00:
>> The usage of threads within libraries is an internal matter, so I think
>> Emacs should be prepared for threads always when<pthread.h>  is available.
>
> That's also my impression.
>
>> Are you thinking of sigwait?  Other than sigwait, there is no way to "set up
>> our signal handlers so we don't need this", where this ==
>> SIGNAL_THREAD_CHECK.
>
> I was afraid so.
>
>> SIGNAL_THREAD_CHECK is not unreliable.  It does not drop signals delivered
>> to the wrong thread, it forwards them to the main thread.
>
> Indeed, I had misread the code.
>
>
>          Stefan