From unknown Sun Sep 07 16:50:23 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79387: 30.1.90; If a thread exits, other threads in wait_reading_process_output aren't woken up Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: dmitry@gutov.dev, eliz@gnu.org, bug-gnu-emacs@gnu.org Resent-Date: Thu, 04 Sep 2025 19:58:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 79387 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 79387@debbugs.gnu.org Cc: Dmitry Gutov , Eli Zaretskii X-Debbugs-Original-To: bug-gnu-emacs@gnu.org X-Debbugs-Original-Xcc: Dmitry Gutov , Eli Zaretskii Received: via spool by submit@debbugs.gnu.org id=B.17570158646513 (code B ref -1); Thu, 04 Sep 2025 19:58:03 +0000 Received: (at submit) by debbugs.gnu.org; 4 Sep 2025 19:57:43 +0000 Received: from localhost ([127.0.0.1]:49388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuG5V-0001gu-8H for submit@debbugs.gnu.org; Thu, 04 Sep 2025 15:57:42 -0400 Received: from lists.gnu.org ([2001:470:142::17]:56636) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuG5L-0001gS-Uh for submit@debbugs.gnu.org; Thu, 04 Sep 2025 15:57:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uuG5F-0007yq-5g for bug-gnu-emacs@gnu.org; Thu, 04 Sep 2025 15:57:25 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uuG5B-0004yw-3s for bug-gnu-emacs@gnu.org; Thu, 04 Sep 2025 15:57:24 -0400 From: Spencer Baugh Date: Thu, 04 Sep 2025 15:57:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1757015838; bh=8DazNHvopFxvQVfXhShDupLYH2dLB8NlaKaEEXzo124=; h=From:To:Subject:Date; b=v90faX1w0jqF+c/WJQ4OnwuZSZLsQqpYWLbzLcZ8nMJed9pTjp3rv43KqqOirIzeT Hgq8JeujjHJzekx//zGx9I5awiTZYWefGFY3s+XsU/CNAmeoF64o5v7z1TCOH+dWA/ umdNI04w7bQBdDEcPt3pVobqmIE+zyx9oAFAdYjJn33tPn39LXk3zTvtimPSGgIqZ/ tFJ+SjQ0kwti6vr8Ct6VCGHTZlqll4Zvrzgu9AVPOGdUMMn7U9yFNlAS2D0DLYPawE O94OWTz5RwuSsNKO8Xhugz6zLXrpU1Nyuuu0EWwWuHlvKFhIBdPlpdbS1b9RHFnRKy hqMnL7Wa4Uisw== Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) 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 From unknown Sun Sep 07 16:50:23 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79387: 30.1.90; If a thread exits, other threads in wait_reading_process_output aren't woken up Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 06:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79387 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: dmitry@gutov.dev, 79387@debbugs.gnu.org Received: via spool by 79387-submit@debbugs.gnu.org id=B79387.17570536938031 (code B ref 79387); Fri, 05 Sep 2025 06:29:01 +0000 Received: (at 79387) by debbugs.gnu.org; 5 Sep 2025 06:28:13 +0000 Received: from localhost ([127.0.0.1]:50653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuPvh-00025Q-2j for submit@debbugs.gnu.org; Fri, 05 Sep 2025 02:28:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37260) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuPvd-000256-L9 for 79387@debbugs.gnu.org; Fri, 05 Sep 2025 02:28:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uuPvX-00059z-Bq; Fri, 05 Sep 2025 02:28:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=XJr2Qz87+jUuc3Uuvrx4r2KMgYfp//yVK+AsHzCuZFA=; b=Um3MgIVigixK 1A6Ec00xAyX3XzBMfP1LObCbo1fvnyIT4Ns0UbM1T16i+BQvtGo5oCi+YvDG4bSZeKRGCFGT9N8qo ymQPKrYGHGt+smxvIk3/CUpemnIRp/w1knr+6EM8b5RyfdEowwvLxBkjctgdWvBqfb5t9L7pZkhqt VITV9VGPwV/zE45ONYKpt0d3YqGk2AThm7k/4h+3EEoiUP3aG90Xd1QEJ5F3OMdl4QQhpewiRyDPR Ut0LxyMrTjZ1Nq58PpNYrpia9UjgMPIYFghIV9d8TAVnGShUQ42HKVnngUcncDUT+mCuY7httkM1t jo5hAStSPtu4U2MduOJLHg==; Date: Fri, 05 Sep 2025 09:27:59 +0300 Message-Id: <86v7lxifbk.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Thu, 04 Sep 2025 15:57:18 -0400) References: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Dmitry Gutov , Eli Zaretskii > From: Spencer Baugh > Date: Thu, 04 Sep 2025 15:57:18 -0400 > > > > 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. As an aside: I don't think I agree with the assertion that thread A monitors most of the descriptors. If you are talking about I/O descriptors due to subprocesses, then each thread should monitor only the subprocesses it started. Whether A will monitor more or less than B depends on how many processes each one of them started. What you describe can only be true if processes are all unlocked. > 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. Yes. Btw, there's also another possibility for thread B to be awoken: if it was stuck not in pselect, but in the following attempt to take the global lock. For example, it could be that its pselect call already returned for some reason. In that case, thread B will start running as soon as thread A exits (assuming there are no other threads competing for the global lock). > I think this is a fairly deep issue with the implementation, which has > probably been causing other weird inconsistencies and bugs. Why is this a problem? You are basically describing an abnormal situation: a thread exited, but the descriptors which only it was monitoring are somehow left open and alive. Nominally, this should not happen: a thread should exit only after all its descriptors are closed and cleaned up. So for an abnormal situation, the fact that some other thread will pick up the orphan descriptors doesn't sound like a serious problem: Emacs is recovering from something that is arguably a bug. > 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. I'm not yet convinced we should try to fix this. It is certainly not as serious a problem as the one with deleting processes locked to other threads, something we need to fix ASAP, and might affect what happens in the situation you describe here. > 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. Yes, let's please fix the other ones 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. First, the results I see are not deterministic, and also system-dependent. On MS-Windows, the process output is consistently printed right after "thread exiting". On GNU/Linux, this also happens, but very rarely; in most runs indeed the process output appears after several seconds. But I fail to understand why this is a problem. A single-threaded Emacs is documented to process output from subprocesses only when it is idle, so the exact timing of the process output being made available to Lisp programs is already not deterministic. In the case of several threads, the timing also depends on what other threads do when the process produces its output. IOW, a program that expects the output to appear after exactly 1 sec just because of "sleep 1" has wrong expectations. Especially since the thread exits without waiting for the output from its process and without shutting down the process, which is basically not clean and arguably a bug. Bottom line: I don't think I see a problem in this case, certainly not a serious one. From unknown Sun Sep 07 16:50:23 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79387: 30.1.90; If a thread exits, other threads in wait_reading_process_output aren't woken up Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Sep 2025 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79387 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: dmitry@gutov.dev, 79387@debbugs.gnu.org Received: via spool by 79387-submit@debbugs.gnu.org id=B79387.175708786825728 (code B ref 79387); Fri, 05 Sep 2025 15:58:02 +0000 Received: (at 79387) by debbugs.gnu.org; 5 Sep 2025 15:57:48 +0000 Received: from localhost ([127.0.0.1]:56069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uuYot-0006gu-GE for submit@debbugs.gnu.org; Fri, 05 Sep 2025 11:57:48 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:35553) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uuYon-0006gP-7D for 79387@debbugs.gnu.org; Fri, 05 Sep 2025 11:57:43 -0400 From: Spencer Baugh In-Reply-To: <86v7lxifbk.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Sep 2025 09:27:59 +0300") References: <86v7lxifbk.fsf@gnu.org> Date: Fri, 05 Sep 2025 11:57:35 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1757087855; bh=Xj7t98yi4E0WkldBQSimPFHqlI7kIDewUEXgGEdMTSk=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=253aFm6S/AkZs8rpY7wpmJmZGb4AS2pbYFEDx7YEEGvwyiBNlQdScVicpPlMrSOnC xUOY7BZ+uPn8P9cdsWMkQGtqZ3cu96TOHdlYbIcEZI5etGY1p5scPXs/AYCOcWeiWT FkjurD1+hQvM0Fs1FUgycg82SXHUQixG7qE8pcM1lnC1apMV+B64P6GkSil2B2QVRK ZspIk2Xw9JObH9YXmLttjrciC747/f1HUlzbbhykmkW5rf31pdzbdMmkEDl4vi3Xa3 Z1xg2FkF88qtOSskgzdClQ5k5xz945dJjrbTiOlqxb8bsHBEUCv0xaORqkIlNYVMtt 5t2Lphkg7JBFA== X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Cc: Dmitry Gutov , Eli Zaretskii >> From: Spencer Baugh >> Date: Thu, 04 Sep 2025 15:57:18 -0400 >> 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. > > I'm not yet convinced we should try to fix this. It is certainly not > as serious a problem as the one with deleting processes locked to > other threads, something we need to fix ASAP, and might affect what > happens in the situation you describe here. I agree it's unlikely to be a serious problem in real-world programs. But nevertheless it's one I would like to fix. Do you think the "associate a pipe with each thread to use for wakeups, and write to it when a thread exits" approach sounds reasonable? BTW, if we added such a pipe it would also be useful for other purposes; if we reimplemented condition-wait by using this pipe, that would resolve my concerns about locked processes, so we'd be able to finally drop that topic and move forward with the "processes are locked by default" behavior. >> 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. > > Yes, let's please fix the other ones first. I'm working on both. There's no rush. I discovered these bugs and all the other thread bugs I've posted recently, and I will fix them in whatever order I prefer. I will fix them all eventually, I promise. I keep discovering additional bugs as I work on fixing the bugs I've already discovered. This is good: the more bugs I discover, the more I understand what is wrong about the system. It may be that these individual bugs are a symptom of a single deeper problem, and I can fix all of them with a change to fix that problem, once I understand enough. So I will follow my own software development approach, and hopefully you will not block that. Again, there's no rush. The bugs I've reported have been in Emacs for many years. >> 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. > > First, the results I see are not deterministic, and also > system-dependent. On MS-Windows, the process output is consistently > printed right after "thread exiting". On GNU/Linux, this also > happens, but very rarely; in most runs indeed the process output > appears after several seconds. Yes, that sounds likely. My fix will make the behavior deterministic and not system-dependent. > But I fail to understand why this is a problem. A single-threaded > Emacs is documented to process output from subprocesses only when it > is idle, so the exact timing of the process output being made > available to Lisp programs is already not deterministic. In the case > of several threads, the timing also depends on what other threads do > when the process produces its output. IOW, a program that expects the > output to appear after exactly 1 sec just because of "sleep 1" has > wrong expectations. That's all true. However, a program can reasonably expect that its process output will appear eventually, and this bug means that the process output might *never* appear, if other threads aren't experiencing timeouts or events. > Especially since the thread exits without waiting for the output from > its process and without shutting down the process, which is basically > not clean and arguably a bug. A thread might exit due to a bug and leave a process object lying around, indeed. But if that results in that process object becoming stuck, and never running its filter and sentinel again even if the OS process is writing output or has exited, that seems bad. From unknown Sun Sep 07 16:50:23 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79387: 30.1.90; If a thread exits, other threads in wait_reading_process_output aren't woken up Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 06:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79387 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: dmitry@gutov.dev, 79387@debbugs.gnu.org Received: via spool by 79387-submit@debbugs.gnu.org id=B79387.175714062718369 (code B ref 79387); Sat, 06 Sep 2025 06:38:02 +0000 Received: (at 79387) by debbugs.gnu.org; 6 Sep 2025 06:37:07 +0000 Received: from localhost ([127.0.0.1]:32854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uumXq-0004mA-C2 for submit@debbugs.gnu.org; Sat, 06 Sep 2025 02:37:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54550) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uumXh-0004kz-Tp for 79387@debbugs.gnu.org; Sat, 06 Sep 2025 02:36:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uumXZ-0004oH-Nf; Sat, 06 Sep 2025 02:36:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jES4UrzFkDkwvI1DFIasBcND6ddo6keRD/CHris+yBA=; b=OdB3SjGvFgbe xvToAC4eZGQ41VXMuCtCq+GcL0APS2kOZ/rIIIZ6rlFdUjCcfYqz2PnZbahprYUsDNH7myrqwVHAF uibqiinYF3l1UIa0NMudO1KtrQcuBWs43gS5QLoUcli37oVmDVMG4FQ+qipsJb17bvl7V33jSx81R UntzkdFb50wCTXWzRPRVxJls8vP/qv/YwLhAYxJEvicwy95LhHyvKB1lWKcpdZD6qtysKhSyhDPGX 3C6ROhcWw1C8W2feXx1cqCSUDgmw+nYVSJSufXSMyi3uzz2aIyD6Kvna6LUEK5/F95y2EuclQX6tN XRuAiEF120K2/9P73d6oiA==; Date: Sat, 06 Sep 2025 09:36:46 +0300 Message-Id: <86bjnohytd.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Fri, 05 Sep 2025 11:57:35 -0400) References: <86v7lxifbk.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: dmitry@gutov.dev, 79387@debbugs.gnu.org > Date: Fri, 05 Sep 2025 11:57:35 -0400 > > Eli Zaretskii writes: > > I'm not yet convinced we should try to fix this. It is certainly not > > as serious a problem as the one with deleting processes locked to > > other threads, something we need to fix ASAP, and might affect what > > happens in the situation you describe here. > > I agree it's unlikely to be a serious problem in real-world programs. > But nevertheless it's one I would like to fix. > > Do you think the "associate a pipe with each thread to use for wakeups, > and write to it when a thread exits" approach sounds reasonable? I'd prefer not to, because a self-pipe is not portable enough. Moreover, when a thread exits, it releases the global lock, so some other thread will start running, and Emacs will eventually watch the processes that are still alive when it becomes idle. So we already have a mechanism for recovering from these situations, to some extent. > BTW, if we added such a pipe it would also be useful for other purposes; > if we reimplemented condition-wait by using this pipe, that would > resolve my concerns about locked processes, so we'd be able to finally > drop that topic and move forward with the "processes are locked by > default" behavior. Let's not introduce infrastructure that complicates the design and the implementation, just because we might need them for some future issue that did not yet happen. > >> 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. > > > > Yes, let's please fix the other ones first. > > I'm working on both. There's no rush. I discovered these bugs and all > the other thread bugs I've posted recently, and I will fix them in > whatever order I prefer. I will fix them all eventually, I promise. The problems with deleting processes locked to other threads is quite serious, and might well affect other issues, since all of the scenarios we are discussing use sub-processes. So I think we should expedite the fix for that problem, and then revisit the others and see whether they still exist and how did the behavior change there. > So I will follow my own software development approach, and hopefully you > will not block that. What is that approach? > > But I fail to understand why this is a problem. A single-threaded > > Emacs is documented to process output from subprocesses only when it > > is idle, so the exact timing of the process output being made > > available to Lisp programs is already not deterministic. In the case > > of several threads, the timing also depends on what other threads do > > when the process produces its output. IOW, a program that expects the > > output to appear after exactly 1 sec just because of "sleep 1" has > > wrong expectations. > > That's all true. However, a program can reasonably expect that its > process output will appear eventually, and this bug means that the > process output might *never* appear, if other threads aren't > experiencing timeouts or events. It's unlikely, because Emacs always processes these events when it is idle. A situation where Emacs never becomes idle means some grave bug, because it means there will be no response for keyboard input, either. In any case, if this is the result of a bug, buggy behavior is to be expected. We don't have to fix bugs of Lisp programs. > > Especially since the thread exits without waiting for the output from > > its process and without shutting down the process, which is basically > > not clean and arguably a bug. > > A thread might exit due to a bug and leave a process object lying > around, indeed. But if that results in that process object becoming > stuck, and never running its filter and sentinel again even if the OS > process is writing output or has exited, that seems bad. I don't see yet how a process could become stuck forever. But even if it does, a buggy Lisp program can cause such bugs, even without threads, and there's nothing here we should care too much to fix in the infrastructure, definitely not by complicating what is already quite complex. From unknown Sun Sep 07 16:50:23 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79387: 30.1.90; If a thread exits, other threads in wait_reading_process_output aren't woken up Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 12:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79387 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Dmitry Gutov , 79387@debbugs.gnu.org Received: via spool by 79387-submit@debbugs.gnu.org id=B79387.175716267019951 (code B ref 79387); Sat, 06 Sep 2025 12:45:02 +0000 Received: (at 79387) by debbugs.gnu.org; 6 Sep 2025 12:44:30 +0000 Received: from localhost ([127.0.0.1]:35037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uusHN-0005Bh-Pr for submit@debbugs.gnu.org; Sat, 06 Sep 2025 08:44:30 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:48503) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uusHE-0005B9-66 for 79387@debbugs.gnu.org; Sat, 06 Sep 2025 08:44:21 -0400 Received: from mail-lj1-f199.google.com ([209.85.208.199]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.98.2) id 1uusH8-00000003KdK-151y for 79387@debbugs.gnu.org; Sat, 06 Sep 2025 08:44:14 -0400 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-336ae9f3e22so12709341fa.1 for <79387@debbugs.gnu.org>; Sat, 06 Sep 2025 05:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1757162653; x=1757767453; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5+nrUrBZGWmySDY7jUKcSpFTOdc2U0cUPS3dS+BD70M=; b=2Ox0P7CIUmlS54h67G4hoQ/bvv/IHaeKDz2V1gS+AQFAReLdLQt5UYy0u4uP3UoKrg 1J0De7alMIMgyFZ07LaxxzFPRehEtMm0L3Rry5lRciF5aQCcWYLUt4HjGOF2DUCRhE9G FVpHFfqIBAfbxCFDkrIzii/ymRnjaDvA8omwc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1757162654; bh=5+nrUrBZGWmySDY7jUKcSpFTOdc2U0cUPS3dS+BD70M=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=MJVk60/ljuv03Hkf2JVphqM1Gz6EXYEVEoQEz2OhPee26zYLq73KEJEkE4tuNKcmV uILTt8Yvr3YBwSbzUAkVUFiE1hXyb+zdZ6qn5HxhirJeMfBipx96gzaijjzH0JavMV l2GGPbJOJWJ7x6SYI9VkEfRSR9lnQEASg4E70cZ9NrC2fqM/2W+8KW4nY78Q87B2HN B+mPGK5TuUoxkr9nFx5X5NZqqZkhy+uepD53HOHgR1n1bYIZZkstIU8sYaNQ0IE0iu USWggt6wcgPpOHRgKCPX5c/GKFGu3i4XW3ZkD6P+vpXJwy2fjUtqGw7CCU8QBOLMK6 fSN7raXt2etIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757162653; x=1757767453; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5+nrUrBZGWmySDY7jUKcSpFTOdc2U0cUPS3dS+BD70M=; b=atIvlXzyeGSNhs8XBpgJhHh8d1Oj+RCOzEWG7JV/STxzbmAMP+a7SuUlMqetQ6WXKQ udwyg+dNdcj8Pm2Gs0rj/MqeyZJKdH6gxP2xWwvo5lkCDyLE1TSdslvjesSJ2laTUZHK 6NKXKbvZnsF9FJVOQfIpgALZ+cv7Vo0gSwT9hO1/CVso79Zbz33M5piOir/r6zSpfL0c hrd1vwoPkvZnTxQOcAIoklMlGpGGvruIJPMS1zzW4S9bUQwHQNwVxkfjMCmkXxA/Cm9K oZQDJAckgWczAUaTh7ROt+/bX5+pUERUj2PPtfGTP4XhhiHPjuQp8rULXQr4xrDr7mC8 qm9A== X-Forwarded-Encrypted: i=1; AJvYcCUgpeUiFmoOWBm3FHwukORKukplrTgoXJynMADqQEqkiiA7Ax8N2jhy4hrid1CooEv0S3lueA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz7zrgV/VsiWZACS3O8I0psvoBLxKnf+tApPQwWpYpG9P/qqJer MFZhqMLhDuV1eH34nPeKLHdvm5M5yZ8onZGxRuHxEAs3pEfjkTh9kgVelxKAyzp/kZawFrkFf1v seG3Xfa34LRAZMsAUTs2RvcYGqhYcHePt2rkO42z1t5fp18QAs5m19kq0fRKwYpbxhAqgdhIxLf mEyQOiHvP1bWrwkR+SjBlaNFsA/cdtiQ== X-Gm-Gg: ASbGncuFr252AjwYRXAoVukEmwjdwb61FG88ywdK7TBq/blpmC3pJgNBWsnHkI0Rv1/ 9pxAg2BUJRsjCUp64UL31gBQuogvEtQjnBiLllRFWZDKvwxnJuQLON2Ao7YmFgMB8TQXm/tUeyn DWpYgV7uxlOr42hUWHy7Rv X-Received: by 2002:a05:6512:3c9a:b0:560:827f:9ff4 with SMTP id 2adb3069b0e04-562636d62b6mr523294e87.27.1757162652877; Sat, 06 Sep 2025 05:44:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH+nBnI+fJe70M9y/MJhKGcjrbFc9NbHPpGgELUD0Wu2IvL0z4W3nrhrIWTZeqMz+MukCEyQ4gSqegFagkw0WU= X-Received: by 2002:a05:6512:3c9a:b0:560:827f:9ff4 with SMTP id 2adb3069b0e04-562636d62b6mr523288e87.27.1757162652415; Sat, 06 Sep 2025 05:44:12 -0700 (PDT) MIME-Version: 1.0 References: <86v7lxifbk.fsf@gnu.org> <86bjnohytd.fsf@gnu.org> In-Reply-To: <86bjnohytd.fsf@gnu.org> From: Spencer Baugh Date: Sat, 6 Sep 2025 08:44:03 -0400 X-Gm-Features: Ac12FXycoXARsjBvbAzQxGhzAYOjr92tTrxGALN7vm4aA3yf9JRlwty4rSxaUvI Message-ID: Content-Type: multipart/alternative; boundary="000000000000b5cbb5063e214fce" X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) --000000000000b5cbb5063e214fce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Sep 6, 2025, 2:36=E2=80=AFAM Eli Zaretskii wrote: > > From: Spencer Baugh > > Cc: dmitry@gutov.dev, 79387@debbugs.gnu.org > > Date: Fri, 05 Sep 2025 11:57:35 -0400 > > > > Eli Zaretskii writes: > > > I'm not yet convinced we should try to fix this. It is certainly not > > > as serious a problem as the one with deleting processes locked to > > > other threads, something we need to fix ASAP, and might affect what > > > happens in the situation you describe here. > > > > I agree it's unlikely to be a serious problem in real-world programs. > > But nevertheless it's one I would like to fix. > > > > Do you think the "associate a pipe with each thread to use for wakeups, > > and write to it when a thread exits" approach sounds reasonable? > > I'd prefer not to, because a self-pipe is not portable enough. > Interesting, what Emacs platform supports threads but does not support pipes? I think on the contrary that it is portable to all the Emacs platforms with threads. > BTW, if we added such a pipe it would also be useful for other purposes; > > if we reimplemented condition-wait by using this pipe, that would > > resolve my concerns about locked processes, so we'd be able to finally > > drop that topic and move forward with the "processes are locked by > > default" behavior. > > Let's not introduce infrastructure that complicates the design and the > implementation, just because we might need them for some future issue > that did not yet happen. > Huh? We're still arguing about the locked processes thing across many bugs, and I've described repeatedly how locked processes can have negative effects. Do I really need to derail this bug into talking about that too? Can you just take it as a given that I believe there's issues with locked processes and condition-wait, and a reimplementation of condition-wait along these lines would solve it in my eyes? > >> Sorry to open up yet another thread bug, but while working on fixes fo= r > > >> 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. > > > > > > Yes, let's please fix the other ones first. > > > > I'm working on both. There's no rush. I discovered these bugs and all > > the other thread bugs I've posted recently, and I will fix them in > > whatever order I prefer. I will fix them all eventually, I promise. > > The problems with deleting processes locked to other threads is quite > serious, and might well affect other issues, since all of the > scenarios we are discussing use sub-processes. So I think we should > expedite the fix for that problem, and then revisit the others and see > whether they still exist and how did the behavior change there. > > > So I will follow my own software development approach, and hopefully yo= u > > will not block that. > > What is that approach? > Discovering bugs and prioritizing solving them according to what I think is best. --000000000000b5cbb5063e214fce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Sep 6, 2025, 2:36=E2=80= =AFAM Eli Zaretskii <eliz@gnu.org>= ; wrote:
> From: Spencer Baugh &= lt;sbaugh@janestreet.com>
> Cc: dmitry@gutov.dev,=C2=A0 79387@debbugs.gnu.org
> Date: Fri, 05 Sep 2025 11:57:35 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
> > I'm not yet convinced we should try to fix this.=C2=A0 It is = certainly not
> > as serious a problem as the one with deleting processes locked to=
> > other threads, something we need to fix ASAP, and might affect wh= at
> > happens in the situation you describe here.
>
> I agree it's unlikely to be a serious problem in real-world progra= ms.
> But nevertheless it's one I would like to fix.
>
> Do you think the "associate a pipe with each thread to use for wa= keups,
> and write to it when a thread exits" approach sounds reasonable?<= br>
I'd prefer not to, because a self-pipe is not portable enough.

Interesti= ng, what Emacs platform supports threads but does not support pipes?
<= div dir=3D"auto">
I think on the contrary that i= t is portable to all the Emacs platforms with threads.

> BTW, if we added such a pipe it would also be useful for other purpose= s;
> if we reimplemented condition-wait by using this pipe, that would
> resolve my concerns about locked processes, so we'd be able to fin= ally
> drop that topic and move forward with the "processes are locked b= y
> default" behavior.

Let's not introduce infrastructure that complicates the design and the<= br> implementation, just because we might need them for some future issue
that did not yet happen.

=
Huh?=C2=A0 We're still arguing about the locked= processes thing across many bugs, and I've described repeatedly how lo= cked processes can have negative effects.=C2=A0 Do I really need to derail = this bug into talking about that too?=C2=A0 Can you just take it as a given= that I believe there's issues with locked processes and condition-wait= , and a reimplementation of condition-wait along these lines would solve it= in my eyes?

> >> Sorry to open up yet another thread bug, but while working on= fixes for
> >> the other ones, I ran into this.=C2=A0 And I think this one i= s a fairly
> >> fundamental problem which will require more substantial chang= es, so
> >> let's fix this one first.
> >
> > Yes, let's please fix the other ones first.
>
> I'm working on both.=C2=A0 There's no rush.=C2=A0 I discovered= these bugs and all
> the other thread bugs I've posted recently, and I will fix them in=
> whatever order I prefer.=C2=A0 I will fix them all eventually, I promi= se.

The problems with deleting processes locked to other threads is quite
serious, and might well affect other issues, since all of the
scenarios we are discussing use sub-processes.=C2=A0 So I think we should expedite the fix for that problem, and then revisit the others and see
whether they still exist and how did the behavior change there.

> So I will follow my own software development approach, and hopefully y= ou
> will not block that.

What is that approach?

Discovering bugs and prioritizing solving them accord= ing to what I think is best.
--000000000000b5cbb5063e214fce-- From unknown Sun Sep 07 16:50:23 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79387: 30.1.90; If a thread exits, other threads in wait_reading_process_output aren't woken up Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 13:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79387 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Spencer Baugh Cc: dmitry@gutov.dev, 79387@debbugs.gnu.org Received: via spool by 79387-submit@debbugs.gnu.org id=B79387.175716493927558 (code B ref 79387); Sat, 06 Sep 2025 13:23:01 +0000 Received: (at 79387) by debbugs.gnu.org; 6 Sep 2025 13:22:19 +0000 Received: from localhost ([127.0.0.1]:35161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uusrx-0007AO-DP for submit@debbugs.gnu.org; Sat, 06 Sep 2025 09:22:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52474) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uusri-00079c-CI for 79387@debbugs.gnu.org; Sat, 06 Sep 2025 09:22:06 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uusrY-0007nR-28; Sat, 06 Sep 2025 09:21:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gm4gWPItKqCCB7wAhjUJbFWC7lxCS8y6KOAwbAeYXPg=; b=dmefRjSyOyTw I69U1bsT66rYysut4eaCoW++OBot+NxM8B10ikqpPkRhOojBtiqq7LQKF8PpB1Xags0dJMkccZtJE TZbpOjL8xkUlaiprEnLeB0BXnLpJTnrNzO8MAUHAVARjCNxSAr4GCFSRn+6K96f2yAbhtyci8V1v7 L9PybdDWKu5quhJ4+KsKN0ZG3ZyEjnu14aSP4Q/fOisL7dcWsSzDjgurn9aoR7kEKFrCi4Fc7An7Y RfZtlICqe9qiAjloaQtxRfOdJTTRFJwbRNod+EL67jzq+dewsnem3UwraD4A+eeJF5UeIyoqfDHEp 0XWHaseURuvSQXxDJgOynw==; Date: Sat, 06 Sep 2025 16:21:48 +0300 Message-Id: <86ecsjg1hv.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Spencer Baugh on Sat, 6 Sep 2025 08:44:03 -0400) References: <86v7lxifbk.fsf@gnu.org> <86bjnohytd.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Sat, 6 Sep 2025 08:44:03 -0400 > Cc: Dmitry Gutov , 79387@debbugs.gnu.org > > > Do you think the "associate a pipe with each thread to use for wakeups, > > and write to it when a thread exits" approach sounds reasonable? > > I'd prefer not to, because a self-pipe is not portable enough. > > Interesting, what Emacs platform supports threads but does not support pipes? > > I think on the contrary that it is portable to all the Emacs platforms with threads. Not pipes, but pipes whose reading and writing edges are the same program. Windows doesn't support that, and I'm not sure about other platforms. > > BTW, if we added such a pipe it would also be useful for other purposes; > > if we reimplemented condition-wait by using this pipe, that would > > resolve my concerns about locked processes, so we'd be able to finally > > drop that topic and move forward with the "processes are locked by > > default" behavior. > > Let's not introduce infrastructure that complicates the design and the > implementation, just because we might need them for some future issue > that did not yet happen. > > Huh? We're still arguing about the locked processes thing across many bugs, and I've described repeatedly > how locked processes can have negative effects. Do I really need to derail this bug into talking about that > too? Can you just take it as a given that I believe there's issues with locked processes and condition-wait, > and a reimplementation of condition-wait along these lines would solve it in my eyes? Sorry, you lost me here. > > >> 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. > > > > > > Yes, let's please fix the other ones first. > > > > I'm working on both. There's no rush. I discovered these bugs and all > > the other thread bugs I've posted recently, and I will fix them in > > whatever order I prefer. I will fix them all eventually, I promise. > > The problems with deleting processes locked to other threads is quite > serious, and might well affect other issues, since all of the > scenarios we are discussing use sub-processes. So I think we should > expedite the fix for that problem, and then revisit the others and see > whether they still exist and how did the behavior change there. > > > So I will follow my own software development approach, and hopefully you > > will not block that. > > What is that approach? > > Discovering bugs and prioritizing solving them according to what I think is best. That's fine, but I'd prefer that bugs that are serious get prioritized higher than discovering other bugs. From unknown Sun Sep 07 16:50:23 2025 X-Loop: help-debbugs@gnu.org Subject: bug#79387: 30.1.90; If a thread exits, other threads in wait_reading_process_output aren't woken up Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Sep 2025 13:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 79387 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: sbaugh@janestreet.com Cc: dmitry@gutov.dev, 79387@debbugs.gnu.org Received: via spool by 79387-submit@debbugs.gnu.org id=B79387.175716514728882 (code B ref 79387); Sat, 06 Sep 2025 13:26:02 +0000 Received: (at 79387) by debbugs.gnu.org; 6 Sep 2025 13:25:47 +0000 Received: from localhost ([127.0.0.1]:35194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uusvG-0007Vf-Jj for submit@debbugs.gnu.org; Sat, 06 Sep 2025 09:25:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58354) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uusv9-0007VI-LT for 79387@debbugs.gnu.org; Sat, 06 Sep 2025 09:25:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uusv2-0008Fr-QU; Sat, 06 Sep 2025 09:25:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=BCElEYHGc0SsxxSGt/8MMshpfRaaFEUpKdtcyQWqAxc=; b=oov49FbXxjA1 6awSLhPftSe0VYQI8K3XKU/V6LCjIuOq6cjirvdmibzSsro+84N/LWWeapUQ3WE3Zc9N+t/qrrmw3 Pc3UXWeMduLyTM+x0M9jggMqewhujvAt6oZCDt6Jn7xXm77OqzG8+F/xs6ErYQoD4WApqNUOwEJmm EzLYAo8vHf40oyHymuXQDkak5R39kVJHd5Z0OkVGW6ND2ZhYUf0K8x62dQqN238ifl0p37YBf6VF7 ouG/bR/8HdchV2VY/Rhs2bxWwKRGl+Mwkl843RvOfF1Uv6mIj73uv8dIGDfvdEITFFqMDf8R6V9ob gDwYYUQPuctrVaa2BKFSnA==; Date: Sat, 06 Sep 2025 16:25:22 +0300 Message-Id: <86cy83g1bx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86ecsjg1hv.fsf@gnu.org> (message from Eli Zaretskii on Sat, 06 Sep 2025 16:21:48 +0300) References: <86v7lxifbk.fsf@gnu.org> <86bjnohytd.fsf@gnu.org> <86ecsjg1hv.fsf@gnu.org> X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Cc: dmitry@gutov.dev, 79387@debbugs.gnu.org > Date: Sat, 06 Sep 2025 16:21:48 +0300 > From: Eli Zaretskii > > > From: Spencer Baugh > > Date: Sat, 6 Sep 2025 08:44:03 -0400 > > Cc: Dmitry Gutov , 79387@debbugs.gnu.org > > > > > Do you think the "associate a pipe with each thread to use for wakeups, > > > and write to it when a thread exits" approach sounds reasonable? > > > > I'd prefer not to, because a self-pipe is not portable enough. > > > > Interesting, what Emacs platform supports threads but does not support pipes? > > > > I think on the contrary that it is portable to all the Emacs platforms with threads. > > Not pipes, but pipes whose reading and writing edges are the same > program. Windows doesn't support that, and I'm not sure about other > platforms. Or maybe it's possible, but I don't know how to do that.