On Sat, Sep 6, 2025, 2:36 AM Eli Zaretskii <
eliz@gnu.org> wrote:
> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: dmitry@gutov.dev, 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. 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.