bug#73131: 28.2; Yielded threads get killed on C-g

bug#73131: 28.2; Yielded threads get killed on C-g

[Swapneil Singh]

When using the Emacs cooperative threading system in a new project, I
noticed that calling C-g results in quitting the background thread I
create, even when those threads are yielded.

Sending this as a bug report per Eli Zaretskii's mention that it may not
be expected behavior
(https://www.reddit.com/r/emacs/comments/1fbkkii/comment/lm3boja/).

Repro recipe:
- emacs -Q
- `C-x 3` and run `list-threads` in the new window, then return to the
older window
- `M-:` `(make-thread (lambda () (cl-loop while t do (progn
(thread-yield) (sleep-for 30)))))` and wait for the new thread to yield to
the main thread.
- `C-g`. The new thread disappears from the `list-threads` window.


Note: While I am admittedly on Windows, given this behavior is within the
cooperative threads of the Emacs runtime (rather than actual Windows
threads) I *really* doubt that has anything to do with it.

In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-09-13 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.22631
System Description: Microsoft Windows 10 Home (v10.0.2009.22631.4037)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs
password-cache json map text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
mule-util thread backtrace find-func novice comp comp-cstr warnings
subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv cl-loaddefs
cl-lib bytecomp byte-compile cconv iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer 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 emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads w32notify
w32 lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 84196 8508)
 (symbols 48 8108 1)
 (strings 32 24204 4130)
 (string-bytes 1 796675)
 (vectors 16 17957)
 (vector-slots 8 324199 20918)
 (floats 8 36 215)
 (intervals 56 256 36)
 (buffers 992 15))

bug#73131: 28.2; Yielded threads get killed on C-g

[Andrea Corallo]

Swapneil Singh <swapneil.singh@gmail.com> writes:

> When using the Emacs cooperative threading system in a new project, I
> noticed that calling C-g results in quitting the background thread I
> create, even when those threads are yielded.
>
> Sending this as a bug report per Eli Zaretskii's mention that it may not
> be expected behavior
> (https://www.reddit.com/r/emacs/comments/1fbkkii/comment/lm3boja/).
>
> Repro recipe:
> - emacs -Q
> - `C-x 3` and run `list-threads` in the new window, then return to the
> older window
> - `M-:` `(make-thread (lambda () (cl-loop while t do (progn
> (thread-yield) (sleep-for 30)))))` and wait for the new thread to yield to
> the main thread.
> - `C-g`. The new thread disappears from the `list-threads` window.
>
>
> Note: While I am admittedly on Windows, given this behavior is within the
> cooperative threads of the Emacs runtime (rather than actual Windows
> threads) I *really* doubt that has anything to do with it.

Data point: I might be doing something different but I can't reproduce
this here on emacs-29.4 nor on emacs30 on GNU/Linux.

  Andrea

bug#73131: 28.2; Yielded threads get killed on C-g

[Eli Zaretskii]

> From: Swapneil Singh <swapneil.singh@gmail.com>
> Date: Sun, 8 Sep 2024 12:08:00 -0400
> 
> When using the Emacs cooperative threading system in a new project, I
> noticed that calling C-g results in quitting the background thread I
> create, even when those threads are yielded.
> 
> Sending this as a bug report per Eli Zaretskii's mention that it may not
> be expected behavior
> (https://www.reddit.com/r/emacs/comments/1fbkkii/comment/lm3boja/).
> 
> Repro recipe:
> - emacs -Q
> - `C-x 3` and run `list-threads` in the new window, then return to the
> older window
> - `M-:` `(make-thread (lambda () (cl-loop while t do (progn
> (thread-yield) (sleep-for 30)))))` and wait for the new thread to yield to
> the main thread.
> - `C-g`. The new thread disappears from the `list-threads` window.
> 
> 
> Note: While I am admittedly on Windows, given this behavior is within the
> cooperative threads of the Emacs runtime (rather than actual Windows
> threads) I *really* doubt that has anything to do with it.

Actually, your being on MS-Windows does explain what you see, because
the way C-g is processed is system-dependent.  When I said "this is
not supposed to happen", I assumed you were doing this on GNU/Linux or
another Posix platform.

Indeed, on MS-Windows this is expected behavior: pressing C-g in the
above scenario will set the quit-flag, and the loop will then quit.
To prevent that, you need to use this simple technique:

  (make-thread
   (lambda ()
     (let ((inhibit-quit t))  ;; <<<<<<<<<<<<<<<<<<<<
       (cl-loop
	while t do
	(progn
	  (thread-yield)
	  (sleep-for 30))))))

Btw, my recommendation is to bind inhibit-quit non-nil around the
thread functions in all cases, if you want background thread to never
be interrupted by C-g and the like.

bug#73131: 28.2; Yielded threads get killed on C-g

[Swapneil Singh]

inhibit-quit works great, thanks for the fix!

On Mon, Sep 9, 2024 at 8:22 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Swapneil Singh <swapneil.singh@gmail.com>
> > Date: Sun, 8 Sep 2024 12:08:00 -0400
> >
> > When using the Emacs cooperative threading system in a new project, I
> > noticed that calling C-g results in quitting the background thread I
> > create, even when those threads are yielded.
> >
> > Sending this as a bug report per Eli Zaretskii's mention that it may not
> > be expected behavior
> > (https://www.reddit.com/r/emacs/comments/1fbkkii/comment/lm3boja/).
> >
> > Repro recipe:
> > - emacs -Q
> > - `C-x 3` and run `list-threads` in the new window, then return to the
> > older window
> > - `M-:` `(make-thread (lambda () (cl-loop while t do (progn
> > (thread-yield) (sleep-for 30)))))` and wait for the new thread to yield to
> > the main thread.
> > - `C-g`. The new thread disappears from the `list-threads` window.
> >
> >
> > Note: While I am admittedly on Windows, given this behavior is within the
> > cooperative threads of the Emacs runtime (rather than actual Windows
> > threads) I *really* doubt that has anything to do with it.
>
> Actually, your being on MS-Windows does explain what you see, because
> the way C-g is processed is system-dependent.  When I said "this is
> not supposed to happen", I assumed you were doing this on GNU/Linux or
> another Posix platform.
>
> Indeed, on MS-Windows this is expected behavior: pressing C-g in the
> above scenario will set the quit-flag, and the loop will then quit.
> To prevent that, you need to use this simple technique:
>
>   (make-thread
>    (lambda ()
>      (let ((inhibit-quit t))  ;; <<<<<<<<<<<<<<<<<<<<
>        (cl-loop
>         while t do
>         (progn
>           (thread-yield)
>           (sleep-for 30))))))
>
> Btw, my recommendation is to bind inhibit-quit non-nil around the
> thread functions in all cases, if you want background thread to never
> be interrupted by C-g and the like.