GNU bug report logs - #73131
28.2; Yielded threads get killed on C-g

Previous Next

Package: emacs;

Reported by: Swapneil Singh <swapneil.singh <at> gmail.com>

Date: Mon, 9 Sep 2024 04:09:01 UTC

Severity: normal

Found in version 28.2

To reply to this bug, email your comments to 73131 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#73131; Package emacs. (Mon, 09 Sep 2024 04:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Swapneil Singh <swapneil.singh <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 09 Sep 2024 04:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Swapneil Singh <swapneil.singh <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.2; Yielded threads get killed on C-g
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.

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))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#73131; Package emacs. (Mon, 09 Sep 2024 06:50:02 GMT) Full text and rfc822 format available.

Message #8 received at 73131 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Swapneil Singh <swapneil.singh <at> gmail.com>
Cc: 73131 <at> debbugs.gnu.org
Subject: Re: bug#73131: 28.2; Yielded threads get killed on C-g
Date: Mon, 09 Sep 2024 02:47:07 -0400
Swapneil Singh <swapneil.singh <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#73131; Package emacs. (Mon, 09 Sep 2024 12:24:02 GMT) Full text and rfc822 format available.

Message #11 received at 73131 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Swapneil Singh <swapneil.singh <at> gmail.com>
Cc: 73131 <at> debbugs.gnu.org
Subject: Re: bug#73131: 28.2; Yielded threads get killed on C-g
Date: Mon, 09 Sep 2024 15:22:48 +0300
> From: Swapneil Singh <swapneil.singh <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#73131; Package emacs. (Tue, 10 Sep 2024 05:48:02 GMT) Full text and rfc822 format available.

Message #14 received at 73131 <at> debbugs.gnu.org (full text, mbox):

From: Swapneil Singh <swapneil.singh <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73131 <at> debbugs.gnu.org
Subject: Re: bug#73131: 28.2; Yielded threads get killed on C-g
Date: Tue, 10 Sep 2024 01:45:39 -0400
inhibit-quit works great, thanks for the fix!

On Mon, Sep 9, 2024 at 8:22 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Swapneil Singh <swapneil.singh <at> 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.




This bug report was last modified 334 days ago.

Previous Next


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