On Sat, Sep 6, 2025, 2:36 AM 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 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.