GNU bug report logs -
#73131
28.2; Yielded threads get killed on C-g
Previous Next
To reply to this bug, email your comments to 73131 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
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):
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: 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):
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.