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

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

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

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1.90; If a thread exits, other threads in
 wait_reading_process_output aren't woken up
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.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: dmitry <at> gutov.dev, 79387 <at> debbugs.gnu.org
Subject: Re: bug#79387: 30.1.90;
 If a thread exits, other threads in wait_reading_process_output
 aren't woken up
Date: Fri, 05 Sep 2025 09:27:59 +0300

> Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> 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.

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dmitry <at> gutov.dev, 79387 <at> debbugs.gnu.org
Subject: Re: bug#79387: 30.1.90; If a thread exits, other threads in
 wait_reading_process_output aren't woken up
Date: Fri, 05 Sep 2025 11:57:35 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: Dmitry Gutov <dmitry <at> gutov.dev>, Eli Zaretskii <eliz <at> gnu.org>
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: dmitry <at> gutov.dev, 79387 <at> debbugs.gnu.org
Subject: Re: bug#79387: 30.1.90; If a thread exits, other threads in
 wait_reading_process_output aren't woken up
Date: Sat, 06 Sep 2025 09:36:46 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: dmitry <at> gutov.dev,  79387 <at> debbugs.gnu.org
> Date: Fri, 05 Sep 2025 11:57:35 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79387 <at> debbugs.gnu.org
Subject: Re: bug#79387: 30.1.90; If a thread exits, other threads in
 wait_reading_process_output aren't woken up
Date: Sat, 6 Sep 2025 08:44:03 -0400

[Message part 1 (text/plain, inline)]

On Sat, Sep 6, 2025, 2:36 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Cc: dmitry <at> gutov.dev,  79387 <at> debbugs.gnu.org
> > Date: Fri, 05 Sep 2025 11:57:35 -0400
> >
> > Eli Zaretskii <eliz <at> gnu.org> 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 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.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: dmitry <at> gutov.dev, 79387 <at> debbugs.gnu.org
Subject: Re: bug#79387: 30.1.90; If a thread exits, other threads in
 wait_reading_process_output aren't woken up
Date: Sat, 06 Sep 2025 16:21:48 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Sat, 6 Sep 2025 08:44:03 -0400
> Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79387 <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> janestreet.com
Cc: dmitry <at> gutov.dev, 79387 <at> debbugs.gnu.org
Subject: Re: bug#79387: 30.1.90;
 If a thread exits, other threads in wait_reading_process_output
 aren't woken up
Date: Sat, 06 Sep 2025 16:25:22 +0300

> Cc: dmitry <at> gutov.dev, 79387 <at> debbugs.gnu.org
> Date: Sat, 06 Sep 2025 16:21:48 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Spencer Baugh <sbaugh <at> janestreet.com>
> > Date: Sat, 6 Sep 2025 08:44:03 -0400
> > Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79387 <at> 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.

Previous Next

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