bug#31671: 26.1; edebug-defun doesn't step if functions run in a separate thread

bug#31671: 26.1; edebug-defun doesn't step if functions run in a separate thread

[Drew Adams]

> The problem here is that Edebug enters recursive-editing (on the
> non-main thread which runs the function 'foo'), then waits for the
> user to press a key.  While it waits, it releases the global lock, and
> the main thread starts running.  So when you press a key, you are on a
> different thread, and 'throw' doesn't have a matching 'catch' (because
> that 'catch' is stored with the handlers of the thread which runs
> 'foo'.
> 
> Not yet sure how to deal with this.  Thoughts and ideas are welcome.

Not really following this thread, and 100% unknowledgable
about Emacs threading.  But somewhat curious: Does the same
problem exist for plain `debug' as for `edebug'?

bug#31671: 26.1; edebug-defun doesn't step if functions run in a separate thread

[Eli Zaretskii]

> Date: Mon, 4 Jun 2018 10:23:58 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 31671@debbugs.gnu.org
> 
> > The problem here is that Edebug enters recursive-editing (on the
> > non-main thread which runs the function 'foo'), then waits for the
> > user to press a key.  While it waits, it releases the global lock, and
> > the main thread starts running.  So when you press a key, you are on a
> > different thread, and 'throw' doesn't have a matching 'catch' (because
> > that 'catch' is stored with the handlers of the thread which runs
> > 'foo'.
> > 
> > Not yet sure how to deal with this.  Thoughts and ideas are welcome.
> 
> Not really following this thread, and 100% unknowledgable
> about Emacs threading.  But somewhat curious: Does the same
> problem exist for plain `debug' as for `edebug'?

Yes.  Modify the recipe like this, and you have the same problem with
'debug':

  emacs -Q
  Type:

    (defun foo ()
      (message "Hi"))

  Eval the function to define it.
  M-x debug-on-entry RET foo RET
  M-: (make-thread 'foo) RET

  Type 'd' in the backtrace that Emacs presents.

bug#31671: 26.1; edebug-defun doesn't step if functions run in a separate thread

[Raimon Grau]

Using edebug-defun to instrument a function and running that function in
a separate thread using `make-thread' makes triggers the breakpoint but
leaves the bufer in read-only-mode but the user can't interact with
edebug in any way.

Steps to reproduce (ubuntu 16.04):
- start emacs with emacs -Q  . 
- in the *scratch* buffer, write:
(defun foo ()
  (message "hi"))

(make-thread 'foo)
- edebug-defun function foo
- c-x c-e the (make-thread 'foo) sexp
- *scratch* buffer point moves to the beginning of function foo
- press `n` and the minibuffers says: "No catch for tag: exit, nil". The
  whole buffer is in read-only mode. modeline has
  "(Lisp Interaction *Debugging* ElDoc)"

The "Recent messages" below correspond exactly to that sequence of
commands.


In GNU Emacs 26.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2018-05-10 built on raikong
Repository revision: 1d9e66aea17787e03954f32c6cd7561c881bb444
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description:	Ubuntu 16.04.4 LTS

Recent messages:
foo
Edebug: foo
foo
#<thread 0x1399d20>

edebug-set-mode: No catch for tag: exit, nil
Making completion list...
(#<thread 0xc11460> #<thread 0x1399d20>)
Making completion list... [2 times]
Edebug will stop after next eval.
edebug-bounce-point: Edebug is not active
command-execute: Buffer is read-only: #<buffer *scratch*>

Configured using:
 'configure --prefix=/home/rgrau/emacs-git
 PKG_CONFIG_PATH=/home/rgrau/.guix-profile/lib/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LCMS2

Important settings:
  value of $LC_MONETARY: es_ES.UTF-8
  value of $LC_NUMERIC: es_ES.UTF-8
  value of $LC_TIME: es_ES.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  edebug-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils edebug easymenu cl-loaddefs cl-lib
elec-pair time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 97842 12105)
 (symbols 48 20713 1)
 (miscs 40 59 143)
 (strings 32 29196 1060)
 (string-bytes 1 768686)
 (vectors 16 14550)
 (vector-slots 8 496991 7738)
 (floats 8 53 323)
 (intervals 56 254 7)
 (buffers 992 12)
 (heap 1024 32030 1223))

bug#31671: 26.1; edebug-defun doesn't step if functions run in a separate thread

[Eli Zaretskii]

> From: Raimon Grau <raimon@konghq.com>
> Date: Thu, 31 May 2018 18:37:17 +0100
> 
> Using edebug-defun to instrument a function and running that function in
> a separate thread using `make-thread' makes triggers the breakpoint but
> leaves the bufer in read-only-mode but the user can't interact with
> edebug in any way.
> 
> Steps to reproduce (ubuntu 16.04):
> - start emacs with emacs -Q  . 
> - in the *scratch* buffer, write:
> (defun foo ()
>   (message "hi"))
> 
> (make-thread 'foo)
> - edebug-defun function foo
> - c-x c-e the (make-thread 'foo) sexp
> - *scratch* buffer point moves to the beginning of function foo
> - press `n` and the minibuffers says: "No catch for tag: exit, nil". The
>   whole buffer is in read-only mode. modeline has
>   "(Lisp Interaction *Debugging* ElDoc)"

The problem here is that Edebug enters recursive-editing (on the
non-main thread which runs the function 'foo'), then waits for the
user to press a key.  While it waits, it releases the global lock, and
the main thread starts running.  So when you press a key, you are on a
different thread, and 'throw' doesn't have a matching 'catch' (because
that 'catch' is stored with the handlers of the thread which runs
'foo'.

Not yet sure how to deal with this.  Thoughts and ideas are welcome.

bug#31671: 26.1; edebug-defun doesn't step if functions run in a separate thread

[Eli Zaretskii]

> Date: Mon, 04 Jun 2018 19:56:28 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 31671@debbugs.gnu.org
> 
> The problem here is that Edebug enters recursive-editing (on the
> non-main thread which runs the function 'foo'), then waits for the
> user to press a key.  While it waits, it releases the global lock, and
> the main thread starts running.  So when you press a key, you are on a
> different thread, and 'throw' doesn't have a matching 'catch' (because
> that 'catch' is stored with the handlers of the thread which runs
> 'foo'.
> 
> Not yet sure how to deal with this.  Thoughts and ideas are welcome.

Any objections to the following band-aid?  (Of course, user-error does
nothing visible on non-main threads, and you have too invoke
thread-last-error to see the error message, but at least we don't
leave around a thread in limbo waiting forever for input that will
never come...)

--- src/thread.c~0	2018-01-28 06:56:25.000000000 +0200
+++ src/thread.c	2018-06-05 17:25:43.147566500 +0300
@@ -980,6 +980,23 @@ DEFUN ("thread-last-error", Fthread_last
   return last_thread_error;
 }
 
+DEFUN ("main-thread-p", Fmain_thread_p, Smain_thread_p, 0, 1, 0,
+       doc: /* Return non-nil if THREAD is the main thread.
+If THREAD is nil or omitted, it defaults to the current thread.  */)
+  (Lisp_Object thread)
+{
+  struct thread_state *tstate;
+
+  if (NILP (thread))
+    tstate = current_thread;
+  else
+    {
+      CHECK_THREAD (thread);
+      tstate = XTHREAD (thread);
+    }
+  return main_thread_p (tstate) ? Qt : Qnil;
+}
+
 \f
 
 bool
@@ -1073,6 +1090,7 @@ syms_of_threads (void)
       defsubr (&Scondition_mutex);
       defsubr (&Scondition_name);
       defsubr (&Sthread_last_error);
+      defsubr (&Smain_thread_p);
 
       staticpro (&last_thread_error);
       last_thread_error = Qnil;
--- lisp/emacs-lisp/edebug.el~0	2018-03-14 06:39:59.000000000 +0200
+++ lisp/emacs-lisp/edebug.el	2018-06-05 17:19:52.017355000 +0300
@@ -2425,6 +2425,8 @@
   (if inhibit-redisplay
       ;; Don't really try to enter edebug within an eval from redisplay.
       value
+    (or (main-thread-p)
+        (user-error "Debugging on non-main thread is not yet supported"))
     ;; Check breakpoints and pending input.
     ;; If edebug display should be updated, call edebug--display.
     ;; Return value.
--- lisp/emacs-lisp/debug.el~0	2018-01-03 13:08:56.000000000 +0200
+++ lisp/emacs-lisp/debug.el	2018-06-05 17:31:39.765134800 +0300
@@ -147,6 +147,8 @@
   (if inhibit-redisplay
       ;; Don't really try to enter debugger within an eval from redisplay.
       debugger-value
+    (or (main-thread-p)
+        (user-error "Debugging on non-main thread is not yet supported"))
     (unless noninteractive
       (message "Entering debugger..."))
     (let (debugger-value
--- doc/lispref/threads.texi~0	2018-01-03 13:08:46.000000000 +0200
+++ doc/lispref/threads.texi	2018-06-05 17:29:47.030735200 +0300
@@ -122,6 +122,12 @@
 Return the current thread.
 @end defun
 
+@defun main-thread-p &optional thread
+This function returns non-@code{nil} if @var{thread} is the main
+thread.  If @var{thread} is @code{nil} or omitted, it defaults to the
+current thread.
+@end defun
+
 @defun all-threads
 Return a list of all the live thread objects.  A new list is returned
 by each invocation.
--- etc/NEWS~	2018-03-14 06:39:58.000000000 +0200
+++ etc/NEWS	2018-06-05 17:37:13.301233500 +0300
@@ -361,6 +361,11 @@
 * Lisp Changes in Emacs 27.1
 
 +++
+** New primitive 'main-thread-p'.
+This can be used in code which needs to work differently when it runs
+in threads other than the main thread.
+
++++
 ** New function assoc-delete-all.
 
 ** 'print-quoted' now defaults to t, so if you want to see