GNU bug report logs -
#79387
30.1.90; If a thread exits, other threads in wait_reading_process_output aren't woken up
Previous Next
Full log
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Expl
Multiple threads can call wait_reading_process_output at the same time, and
we are careful to avoid having multiple threads monitor the same file
descriptors. That's fine and good.
If thread A calls wait_reading_process_output, then it will monitor all
the file descriptors it can. If thread B calls
wait_reading_process_output after that, it will monitor the remaining
file descriptors which aren't already being monitored, such as newly
created processes. Generally, thread B will be monitoring far fewer
file descriptors than thread A, which will be monitoring most of them.
Each thread will handle events on the file descriptors it is monitoring,
as appropriate.
However, there's a fundamental problem with the implementation right
now: if thread A calls wait_reading_process_output and monitors most of
the fds, and thread B calls wait_reading_process_output and monitors
just the remaining fds, then what happens if thread A exits?
Thread B will stay blocked, monitoring just a few file descriptors,
while most of them stay un-monitored. This can happen to the main
thread, for example.
Thread B will stay in this state until some event happens on the file
descriptors it *is* monitoring, or it times out; then either
wait_reading_process_output will return or it will loop. After looping,
it will thankfully pick up all the file descriptors which were
previously being monitored by thread A.
I think this is a fairly deep issue with the implementation, which has
probably been causing other weird inconsistencies and bugs.
To fix this, we need to wake up threads which are blocked in
wait_reading_process_output when another thread exits. This will
require adding a new mechanism to support this. I think a good way is
for thread creation to open a pipe specific to that thread, used for
this purpose; then when a thread is blocked in
wait_reading_process_output, it should monitor this pipe along with
other file descriptors. Then an exiting thread can write to this pipe
to wake up a thread which is currently blocked in
wait_reading_process_output.
Sorry to open up yet another thread bug, but while working on fixes for
the other ones, I ran into this. And I think this one is a fairly
fundamental problem which will require more substantial changes, so
let's fix this one first.
You can reproduce this bug by running this code with "emacs -Q --batch":
;; -*- lexical-binding: t; -*-
(defun my-filter (proc out)
(message "%s %s" proc out))
(make-thread
(lambda ()
(message "starting thread")
(sit-for 1)
(message "making process")
(make-process
:name "true"
:filter #'my-filter
:command '("sh" "-c" "sleep 1 && echo hello && sleep inf"))
(message "thread exiting")))
(message "main thread sleeping")
(sit-for 10)
(message "main thread sleeping again")
(sit-for 10)
The process output will not be printed until the first sit-for is
complete.
In GNU Emacs 30.1.90 (build 43, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.12, Xaw scroll bars) of 2025-09-03 built on
igm-qws-u22796a
Repository revision: 8a831d9c110ea4dd349444de8f99d7cee10c5273
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)
Configured using:
'configure --with-x-toolkit=lucid --without-gpm --without-gconf
--without-selinux --without-imagemagick --with-modules --with-gif=no
--with-cairo --with-rsvg --without-compress-install --with-tree-sitter
--with-native-compilation=aot
PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/'
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
This bug report was last modified 1 day ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.