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

View this message in rfc822 format

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: 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.

Previous Next

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