GNU bug report logs - #79367
31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: i <at> fuzy.me, sbaugh <at> janestreet.com, 79367 <at> debbugs.gnu.org
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
 diff-hl-update-async is t
Date: Tue, 02 Sep 2025 22:18:20 +0300

> Date: Tue, 2 Sep 2025 19:28:05 +0300
> Cc: i <at> fuzy.me, 79367 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> > This particular breakage is simply because my change was incomplete:
> > it left some processes not locked to their thread, and the solution
> > proposed by the OP, which fixed that blunder, is simpler and has fewer
> > downsides than backing out the process locking to threads.  This
> > happens all the time in development, and the conclusion is rarely that
> > the original changes should be backed out, certainly not if there are
> > simpler fixes.
> 
> I do believe that when a change in a long-standing implementation causes 
> an immediate issue we first consider reverting, especially when there is 
> no consensus on the approach.

No, we don't.  Reverting is actually the last resort, reserved for
plain and clear mistakes, and for changes that cause grave regressions
and cannot be fixed soon enough.

> A one-liner change is probably not a big deal by itself, but like 
> Spencer said, the new process should at least follow the locking of its 
> original thread, or something like this. And we still don't have a 
> proposed fix on that.

I can code the proposed fix in a few minutes, if there's agreement to
what I proposed to do.  I'm still uncertain what I proposed is
agreed-upon.  So let me reiterate that:

  . if the process on behalf of which we called
    server_accept_connection was not locked to some thread, undo what
    make_process did to the new process when it called pset_thread
  . otherwise, call set_proc_thread to lock the new process to the
    same thread as the one which caused this call

> I don't want us to spend a lot of time arguing revert-or-no-revert now, 
> but could you, Eli, try to decide on a full example of a buggy scenario 
> which is really solved by thread locking being?

I already described that in so many words.  That is all I can afford.
And please keep in mind that processes were being locked to threads
since day one, just incompletely so.  I didn't invent it just
yesterday out of the blue: it's the original design of processes with
threads.

And if that is not good enough for you, then we will have to agree to
disagree, and leave it at that.  I stand by my opinion.

Previous Next

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