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 #44 received at 79367 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: i <at> fuzy.me, Dmitry Gutov <dmitry <at> gutov.dev>, 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 15:33:46 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

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

Whatever you do, please post your change for review rather than just
pushing it.

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

Can you send that full description again?  Perhaps I can translate it
from words into code for you.

Previous Next

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