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 #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)]

Previous Next

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